Message ordering guarantees — and when order doesn't actually matter
"Will my messages arrive in order?" is the wrong question to ask about a message queue — the right one is "in order relative to what," because every real messaging system gives a much narrower guarantee than global ordering, and assuming otherwise causes real, hard-to-reproduce bugs.
Intermediate
3 min read
Why global ordering across a whole topic is not actually on offer
A topic or exchange that scales by spreading messages across multiple partitions or multiple consumers has already given up on one single, global, total order — messages produced at roughly the same time can land on different partitions, get processed by different consumers, and complete in a different order than they were sent. Expecting "message A was published before message B, so A will be fully processed before B" to hold across the whole system is expecting a guarantee no scalable messaging system actually provides.
Kafka (lesson 2) guarantees order only within a single partition — and since messages with the same key always land in the same partition, this becomes, in practice, a guarantee of per-key ordering: every event for order #123 arrives and gets processed in the order it was produced, but an event for order #123 and an event for order #456 have no ordering relationship to each other at all, even if #456's event was published first.
This is usually exactly the guarantee that actually matters: a consumer processing order #123's events needs to see Created before Paid before Shipped — it almost never needs order #123's events interleaved in a specific global sequence with order #456's unrelated events.
SQS FIFO queues: the same idea, different vocabulary
AWS SQS's standard queues (covered in the Cloud Computing domain) make no ordering promise at all. A separate FIFO queue type exists specifically for when order matters, using a message group ID — functionally the same concept as a Kafka partition key: messages sharing a group ID are delivered in the order they were sent, while messages in different groups have no ordering relationship to each other.
Why most events genuinely don't need ordering at all
A real, common design mistake is assuming ordering matters when it actually doesn't: an EmailConfirmationRequested event and a MetricRecorded event for the same order have no logical dependency on each other — whichever one a consumer processes first produces the identical correct outcome. Reaching for a strict, per-key-ordered setup by default, rather than asking whether a specific event stream actually requires it, adds real partitioning/routing complexity for no benefit. The right question for any new event type is concrete: "if two of this event type for the same entity arrived and were processed in the wrong relative order, would the outcome actually be wrong?" — only a "yes" justifies the ordering machinery.
When even per-key ordering isn't enough: out-of-order delivery despite a single partition
A single Kafka partition or a single FIFO message group preserves production order, but a consumer can still process messages out of relative order if it retries a failed message while later messages in the same key continue arriving and succeeding — a real, subtle gap between "delivered in order" and "successfully completed in order" that becomes directly relevant once lesson 9 covers retries.