An order is created and then cancelled. Both events are published correctly. Yet the shipping system receives the cancellation before the creation event. If it blindly applies events in arrival order, an order that was cancelled may appear active again.
In distributed systems, event occurrence, publication and processing are distinct moments. The order that seems obvious to a human is therefore something the architecture must define and protect.
What exactly must be ordered?
For one order, the final cancellation should not be overwritten by an older creation event. But two unrelated customers' orders do not necessarily need to be processed one after another. A global sequence can reduce parallelism and create a bottleneck.
A more practical ordering boundary is often one order, account or other business entity. Messages can be keyed accordingly or carry sequence numbers. A broker may guarantee ordering within a partition or message group, not across every possible consumer and workload.
Arrival order is not completion order
Even if events are received sequentially, concurrent handlers can finish in a different order. The first may be waiting on an external API while the second completes quickly. Processing and acknowledgement rules matter just as much as transport settings.
Entity versions help consumers recognise stale updates. Instead of overwriting blindly, a consumer can check the version and reject, defer or reconcile an older event.
What strict ordering costs
Serial work within one key limits throughput for that key. A repeatedly failing message may hold up later events. Teams must decide where concurrency is safe, how to handle poison messages and what delay the business can tolerate.
Enforcing global ordering for routine analytics is often unnecessary. Independent records can be processed concurrently, and derived views can use event versions or timestamps where their meaning is well defined.
Start with the business mistake
Before requesting strict ordering, I would ask for the bad outcome we are trying to prevent: a cancelled order reactivated, stock released twice or an incorrect account state. Then we can decide whether per-entity order and consumer-side version checks are enough.
Ordering is not valuable because events ought to look tidy. It is valuable when the wrong sequence changes a real business outcome.