Partitioning: a topic divided into partitions lets multiple consumers and producers work in parallel, and spreads data across brokers for scalability. Throughput scales roughly with the partition count.
2 / 5
How does Kafka decide which partition a message goes to when a key is provided?
Key-based partitioning: Kafka hashes the message key modulo partition count. This guarantees ordering for a given key (e.g., all events for one user) since they share a partition.
3 / 5
What ordering guarantee does Kafka provide?
Partition ordering: messages are strictly ordered within one partition by offset, but there is no global order across partitions. If you need total order, you must use a single partition, sacrificing parallelism.
4 / 5
What is a potential downside of using too many partitions?
Partition overhead: each partition consumes broker resources (file handles, memory) and lengthens rebalance and failover times. Over-partitioning hurts latency and recovery, so the count should match throughput needs.
5 / 5
What is a hot partition problem?
Hot partition: if a few keys dominate (e.g., one huge customer), their partition gets overloaded while others idle. Choosing a higher-cardinality key or a custom partitioner spreads load more evenly.