Kafka medium
What is the primary change in the 'KRaft' (Kafka Raft) metadata mode compared to the legacy cluster architecture?
- A MetaData Self-Management: Kafka brokers manage their own metadata and elect an internal Controller quorum, entirely removing the operational overhead and bottleneck of Apache ZooKeeper.
- B The message body size limit is increased from 1MB to 1GB per record.
- C Consumers are no longer required to commit offsets to any storage.
- D The entire cluster is forced to run on ARM-based CPU architecture ONLY.
Answer: A. MetaData Self-Management: Kafka brokers manage their own metadata and elect an internal Controller quorum, entirely removing the operational overhead and bottleneck of Apache ZooKeeper.
KRaft enables Kafka to support millions of partitions by removing the ZooKeeper bottleneck. It also simplifies the stack, as you only need to manage one system (Kafka) instead of two conflicting systems with different failure modes.
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?