Queues, Streams, Eventing
Kafka partitions: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick.
Reconstruct the unit’s core mechanisms — the partitioner, per-key ordering, consumer-group assignment, the one-way door, and rebalancing — without looking back at the lesson.
- 01What three jobs does the default partitioner's hash(key) % N do at once, and why does conflating them cause design bugs?
- 02Why is per-key ordering free in Kafka, and what is the exact scope of the ordering guarantee?
- 03Explain why consumer parallelism is hard-capped at the partition count.
- 04Why is increasing a topic's partition count a one-way door, and what is the safe alternative?
- 05What is a stop-the-world rebalance, why does it hurt, and what two mechanisms reduce it?
- 06What is hot-partition skew, why do more partitions and more consumers not fix it, and where is the real fix?
If you could reconstruct each answer from memory, you hold the unit’s spine: one partitioner formula does distribution, ordering, and co-location at once; ordering is guaranteed only within a partition; consumer parallelism is hard-capped at the partition count; raising that count rehashes keys and breaks per-key order, so it is a one-way door you provision around or migrate past; and the two production failures — rebalances and hot-partition skew — are tamed by cooperative rebalancing plus static membership, and by fixing the key rather than the count.