Kafka hard
What is the primary function of 'Request Purgatory' in the Kafka Broker architecture?
- A It is a temporary storage area for records that have failed the internal CRC32 checksum check.
- B Managing 'delayed' requests (e.g., waiting for ISR replication or `min.bytes` fetch conditions). It allows the broker to park a request without blocking an active network thread.
- C Storing the log segments that are currently undergoing asynchronous decompression.
- D A specialized garbage collection region for the Kafka Controller's JVM.
Answer: B. Managing 'delayed' requests (e.g., waiting for ISR replication or `min.bytes` fetch conditions). It allows the broker to park a request without blocking an active network thread.
Without Purgatory, every request waiting for an Ack would tie up a thread, leading to thread exhaustion. Purgatory uses a 'Hierarchical Timing Wheel' to check for thousands of timeouts efficiently, waking up the request only when the condition is met or the timeout expires.
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?