A team must choose partition keys for an event stream. What does the choice determine, and what goes wrong when it is chosen carelessly?

What the key determines

Three things at once, and they are in tension:

• Ordering. Events with the same key go to the same partition and are ordered relative to one another. Ordering across different keys is not guaranteed, ever.
• Parallelism. A partition is consumed by one consumer in a group, so the partition count is the maximum useful consumer parallelism.
• Load distribution. Keys hash to partitions, so a skewed key distribution produces a skewed partition load.

The choice is therefore a simultaneous decision about correctness, throughput and balance, which is why it is difficult and why it is hard to change later.

Choosing well

• Key by the entity whose ordering matters — the order, the account, the device, the user. Most correctness requirements are per-entity, not global, and this is what makes partitioning viable at all.
• Verify the key has enough distinct values to spread across the partitions, and that the distribution is reasonably even.
• Check for the celebrity case. One account generating a disproportionate share of events creates a hot partition that no amount of scaling addresses — the same problem as a hot database key, with the same answer: change the key.
• Size partition count for the peak parallelism you will need, since increasing it later changes the key-to-partition mapping and breaks ordering for existing keys — a genuinely disruptive operation.

What goes wrong

• Random or round-robin keys, giving perfect balance and no ordering guarantee at all — which is fine until a consumer needs to apply updates in order and silently applies them out of order.
• A low-cardinality key — a country, a status, a category — so most partitions are idle and one is saturated.
• A hot key from one dominant entity.
• Assuming global ordering, which the system never provided, producing bugs that appear only under load when partitions drift apart.
• Partition count too low, capping consumer parallelism below what throughput requires, with no way to increase it without breaking ordering.
• Partition count enormous, which historically strained the metadata path and still multiplies per-partition overhead.
• Keying on something mutable, so an entity's events move partitions when the value changes — which destroys the ordering guarantee for exactly the entity whose history matters most.

The mitigations for a hot key

The same shape as any hot-key problem: add a bounded suffix to spread the entity across several partitions and accept that ordering is now per-sub-key rather than per-entity — which requires the consumer to tolerate it, and is a correctness decision rather than a tuning one.

Alternatively, handle the dominant entity on a dedicated partition or a separate stream, which preserves ordering and requires routing logic.

The general principle: partition keys are close to irreversible in a running system, because changing them breaks ordering and requires a coordinated reprocessing. They deserve the analysis given to a data model rather than the attention given to a configuration value.