Kafka hard
In a ZooKeeper-based cluster, what is the primary architectural 'bottleneck' during a Controller failover compared to a KRaft-based cluster?
- A The need for a human administrator to manually approve the new controller via a CLI command.
- B Metadata Reload Delay: The new Controller must fetch and parse the full state of every partition and replica from ZooKeeper before it can begin managing the cluster, causing a prolonged 'freeze' for metadata operations.
- C The requirement that the Controller must be the broker with the largest PID (Process ID).
- D The reliance on HTTP/1.1 for internal cluster state synchronization.
Answer: B. Metadata Reload Delay: The new Controller must fetch and parse the full state of every partition and replica from ZooKeeper before it can begin managing the cluster, causing a prolonged 'freeze' for metadata operations.
KRaft (Kafka Raft) solves this by keeping a 'Warm Metadata Quorum'. Because the metadata is already present and replicated across specific brokers, a failover is nearly instantaneous (milliseconds) rather than seconds or minutes, which is critical for huge clusters with 100k+ partitions.
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?