Kafka hard
The `broker.rack` configuration is critical for multi-AZ (Availability Zone) deployments. What is the specific constraint it imposes on the partition leader election algorithm?
- A It ensures that the Leader and all of its Synchronous Followers are physically located on the same rack to maximize replication speed.
- B Infrastructure Diversity: It ensures that Kafka spreads replicas of the same partition across as many distinct racks/zones as possible, protecting the topic against 'Correlated Failures' (e.g., a single power unit failing for a whole rack).
- C It forces all Consumers to always read from the broker with the lowest numerical rack ID.
- D It prevents any single broker from hosting more than 100 partitions.
Answer: B. Infrastructure Diversity: It ensures that Kafka spreads replicas of the same partition across as many distinct racks/zones as possible, protecting the topic against 'Correlated Failures' (e.g., a single power unit failing for a whole rack).
Without rack awareness, Kafka might accidentally put all 3 copies of a partition on 3 brokers that share a single network switch. If that switch dies, the partition is offline. Rack awareness guarantees a 'balanced' spread across failure domains.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- When implementing 'Exactly-Once Semantics' (EOS) in a Kafka stream, what is the role of the `isolation.level=read_committed` setting on the Consumer?
- Historically, which external service was required by Kafka to manage cluster hierarchy, metadata, and leader election status?
- Once a message is successfully appended to a Kafka partition log, what is its mutability status?
- In a Kafka cluster, what is the role of a 'Broker'?
- What is the primary indicator of a bottleneck in a Kafka consumer's processing logic?
- What is the primary architectural role of Apache Kafka in a distributed system?