Kafka hard
What is the primary technical motivation for implementing 'Static Membership' (`group.instance.id`) in a Kafka consumer group?
- A To allow the consumer to bypass the broker and read data directly from the local disk of the nearest storage node.
- B To prevent unnecessary 'Stop-the-World' rebalances during transient events like rolling deployments or short network blips, as long as the member returns within the session timeout.
- C To force the coordinator to use a single master node for all partition assignments.
- D To disable the 'Heartbeat' thread entirely to save on total network bandwidth.
Answer: B. To prevent unnecessary 'Stop-the-World' rebalances during transient events like rolling deployments or short network blips, as long as the member returns within the session timeout.
Normally, a consumer 'Leave' triggers an immediate rebalance. With `group.instance.id`, the Coordinator knows the member is unique. If it disconnects, the Coordinator holds its partition assignment open. This drastically reduces processing downtime during routine maintenance.
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?