Multi-AZ Kafka Architecture

Deploying Apache Kafka across multiple Availability Zones (Multi-AZ) ensures high availability, fault tolerance, and disaster recovery. If an entire data center (AZ) goes down, Kafka continues to operate without data loss.

1. Architecture Diagram

Below is the conceptual architecture of a 3-way Multi-AZ Kafka deployment using 3 Availability Zones (AZ-A, AZ-B, AZ-C).

2. Key Architectural Concepts

1) Odd Number of AZs (Minimum 3)

• Quorum Requirement: Both ZooKeeper and Kafka KRaft (metadata mode) require a majority quorum to elect a leader.
• Failure Survival: With 3 AZs, if 1 AZ completely fails, the remaining 2 AZs still hold the majority ($2 > 3/2$), allowing the cluster to elect a new controller/leader and remain operational.

2) Rack Awareness (broker.rack)

• Kafka uses the concept of "racks" to understand physical infrastructure. In cloud environments, a "rack" maps directly to an Availability Zone.
• By configuring broker.rack, Kafka guarantees that partition replicas are spread across different AZs rather than being placed on the same physical zone.

3. Essential Configurations for Multi-AZ

To ensure data safety and high availability across AZs, the following configuration parameters must be set.

Broker Configurations (server.properties)

Topic Configurations

Client (Producer) Configurations

4. Disaster Recovery & Failover Scenario

When AZ-A Fails (Broker 1 goes offline)

1. Detection: ZooKeeper/KRaft detects that Broker 1 in AZ-A is heartbeat-silent.
2. Leader Election: Since Partition 0's Leader was on Broker 1, Kafka automatically promotes one of the in-sync followers (on Broker 2 or Broker 3) to be the new Leader.
3. Producer/Consumer Redirection: Kafka clients automatically fetch metadata updates, find the new leader location in AZ-B, and resume read/write operations.
4. No Data Loss: Since acks=all and min.insync.replicas=2 were configured, the data was already safely replicated to AZ-B and AZ-C before the crash.