Four Became Six

A topic account-events has 4 partitions and records are keyed by account_id. Per-account ordering matters: the consumer applies balance deltas in the order it reads them. To add throughput, an operator runs --alter --partitions 6 at 14:00. No records are deleted and no consumer is restarted.

record	key	produced at	partition
e1 deposit 200	`A-9134`	13:58	2
e2 withdraw 50	`A-9134`	13:59	2
e3 withdraw 120	`A-9134`	14:04	5
e4 deposit 30	`A-9134`	14:06	5

Partition 2 is 40,000 records behind. Partition 5 is caught up. What is the consequence?

Only records produced after 14:00 are affected, and because e3 and e4 were both produced after the change, all four records for A-9134 remain in a single ordered stream

Ordering for A-9134 is broken across the expansion: partitions 2 and 5 are consumed independently, so e3 and e4 can be applied long before e1 and e2, and nothing in Kafka will re-order them

Kafka redistributes the existing records across the six partitions when the partition count changes, so A-9134 ends up entirely on partition 5 and ordering is preserved

The producer rejects e3 and e4 until every client has refreshed topic metadata, so nothing is written out of order and the only cost is a brief write outage