What problem are we solving?
Imagine two events: an order is created, then cancelled. If a downstream system observes the cancellation before the creation, the result may be confusing or wrong. In another process, ordering may not matter at all: two independent customer updates can be processed in parallel.
The mistake is assuming order is guaranteed when the broker, network, and consumers do not actually provide that guarantee.
How does the approach work?
Ordering is usually enforced inside a useful boundary rather than across the whole system: for one order, account, or customer. Messages with the same key are routed to the same partition or sequential stream and processed in the order they enter it.
This is the key trade-off. Global ordering turns a parallel system into a queue with one major bottleneck. Local ordering preserves scalability across independent entities.
Even with ordering, consumers still need to handle duplicate delivery, crashes after processing, and other situations where the same event may appear more than once.
What does the business get?
The right ordering boundary reduces the risk of invalid state in processes where sequence has financial, operational, or legal meaning: transaction states, balances, and stage transitions.
At the same time, the business avoids paying for strict sequencing where it is not needed. That preserves the ability to scale throughput and process independent work faster.
What does the team get?
The team gets an explicit rule: which events must be ordered, by which key, and what should happen when sequence is violated. That is much safer than hoping messages will “usually arrive correctly.”
Partitioning and consumer design also become clearer: scale can happen across independent keys, but not infinitely inside one sequential stream.
What does the customer get?
The customer gets more predictable state. They are less likely to see an already cancelled order become active again or an older status overwrite a newer one.
When ordering is limited to the places that need it, customers also benefit from faster processing elsewhere.
What do we pay for it?
Strict ordering reduces parallelism. A hot key can become a bottleneck: one large customer or entity must be processed sequentially even when the rest of the system has spare capacity.
The architecture also needs partitioning keys, retry handling, lag monitoring, and sometimes buffering for late events.
When is ordering unnecessary?
If operations are independent or the final result does not depend on sequence, artificial ordering only reduces throughput.
Sometimes it is cheaper to make operations commutative or store state versions than to build a globally ordered stream.
What should we ask before deciding?
- For which business entities does order actually change the result?
- Do we need global ordering or only ordering within one key?
- What happens if an event is duplicated or delayed?
- Which partition key preserves both correctness and enough parallelism?
- How will we detect and repair an ordering violation?
In the end
In distributed systems, ordering is not a natural property. It is an explicit guarantee, and the wider the guarantee, the more expensive it becomes.
For the business, the right choice is to buy ordering only where sequence changes the business outcome, while preserving parallelism and speed everywhere else.