How do you keep events in order?

A topic is split into partitions, and the broker orders messages within a partition only. If OrderCreated lands on partition 0 and OrderUpdated on partition 2 — because the key was random, or absent, or changed between publishes — two consumers read them in parallel and the update can be processed first. Nothing is misconfigured; ordering across partitions was never promised.

The fix is the partition key: use the order id, so every event for one order goes to the same partition and is consumed in publish order. The tradeoff is throughput and skew: fewer distinct keys means fewer partitions doing work, and a hot key — one enormous customer if the key is customer id — concentrates traffic on one partition and one consumer. Random keys maximise throughput and destroy ordering. Ordering is also per producer; two services publishing about the same order are not ordered relative to each other.

Consumers should still be defensive: carry a version or sequence on the event, ignore updates older than the current state, and make handlers idempotent upserts. That protects against replays and against the day the key changes.