When a broker partitions a topic across multiple nodes/logs for parallelism, what ordering guarantee do you keep and what do you lose, and how does the partition key decide this?

## What a partition actually is A **partition** is an independently ordered, appended-to sequence of messages — a topic is not one stream but several parallel streams, each hosted on possibly a different broker node and consumed independently. When a producer publishes, the broker computes which partition it goes to, typically by hashing a **partition key** supplied with the message (e.g., `hash(customerId) mod numPartitions`), or by round-robin if no key is given. - **Within a single partition**, messages are strictly ordered. - **Across partitions**, there is no such guarantee — two messages in different partitions could be produced or consumed in either relative order, because they're independent logs with independent write throughput and independent consumer read progress. ## Why partitioning exists Partitioning exists to break the single-writer, single-reader bottleneck a single ordered log would otherwise impose. If a topic were one totally-ordered sequence, at most one process could safely append at a time and, more importantly, at most one active consumer instance could make progress at a time — parallel workers would have nothing to do. By splitting into P partitions, you get up to P producers writing concurrently and up to P consumers in a group reading concurrently, each fully owning a slice of the traffic. Doubling partitions roughly doubles achievable write and read throughput, bounded by how many broker nodes and consumer instances you actually deploy. ## The trade-off The core trade-off is: **you buy throughput, you sell total ordering.** Any two messages in different partitions have no ordering relationship a consumer can rely on, so business logic depending on strict global sequence cannot be satisfied by a partitioned topic. Choosing a good partition key is itself a trade-off: | Partition key | It gives you | It denies you | |---|---|---| | A high-cardinality, evenly distributed key (e.g., a UUID) | spreads load evenly | gives no ordering guarantee among related-but-different-keyed events | | A coarse, low-cardinality key | preserves more relative ordering | caps effective parallelism no matter how many partitions the topic has | Partition count is also not free to change — increasing partitions typically changes the key-to-partition hashing for future messages, silently breaking the 'same key always goes to the same partition' guarantee across a repartitioning event. ## Failure modes 1. **A hot partition** is the most common production failure: if the chosen key is skewed, one partition's queue backs up and its dedicated consumer becomes the bottleneck while every other partition's consumer sits idle — overall throughput collapses to whatever that one hot partition can handle. 2. **Consumer rebalancing churn** is a second failure mode: when a group has more members than partitions, the extras are simply idle, surprising teams who assume more consumers always means more throughput. 3. **Assuming cross-partition ordering that doesn't exist** is a third, subtler failure: a service reads two related events for the same entity that happen to land in different partitions (a key bug, or a repartition event), processes them out of order, and corrupts derived state — this bug is intermittent and load-dependent, so it often passes testing and only appears under production traffic patterns. ## Worked examples **Kafka** is the canonical example — a topic 'order-events' might have 12 partitions, keyed by `orderId`; all events for a given order hash to the same partition and are delivered in strict order to one consumer, while up to 12 group members process different orders' events fully in parallel. If instead events were keyed by a low-cardinality 'region' field with only 3 values, only 3 of the 12 partitions would ever receive traffic and 9 consumer instances would sit permanently idle — a real, commonly seen misconfiguration. A **ride-hailing platform** partitioning driver location updates by `driverId` ensures a given driver's updates are always processed in order by one consumer, without needing every driver's updates worldwide to be globally ordered, which would be both unnecessary and impossible to scale.