We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You're texting a friend. You send: "Want to grab dinner?" Then: "How about 7pm?" On their screen, the messages appear in reverse order. "How about 7pm?" first, then "Want to grab dinner?" The conversation makes no sense.
Message ordering seems obvious: messages should arrive in the order they were sent. But in distributed systems, it's one of the hardest guarantees to provide. The moment you introduce multiple servers, partitions, retries, or competing consumers, ordering becomes a real engineering challenge.
Think about it: if three consumer instances are reading from the same queue, and each grabs a different message, there's no guarantee they'll process them in order. Consumer A might be slow. Consumer B might crash and retry. Consumer C might finish first even though its message was sent last.
For many use cases, ordering doesn't matter. "Send welcome email" and "create user profile" can happen in any order. But for some (financial transactions, , user activity logs), processing messages out of order causes corrupted state and subtle bugs that are extremely hard to debug.
Global ordering means all messages, across all producers and consumers, are processed in a single total sequence. This is extremely expensive because it requires a single bottleneck: one queue, one consumer, no parallelism. It doesn't scale. A single Kafka partition tops out around 10-50 MB/s. A globally ordered topic with one partition caps your entire system's there.
Partition ordering means messages within the same partition (or shard) are ordered, but messages across different partitions have no ordering relationship. This is how works and it's the practical solution at scale.
Producer A --> Partition 0: [msg1, msg3, msg5] --> Consumer 0 (ordered within partition)
Producer B --> Partition 1: [msg2, msg4, msg6] --> Consumer 1 (ordered within partition)
Within each partition: strictly ordered
Across partitions: no ordering guarantee
The partition key trick. To ensure related messages are ordered, route them to the same partition using a consistent partition key:
| Use Case | Partition Key | Guarantee |
|---|---|---|
| User actions | userId | All actions for user X are ordered |
| Order events | orderId | Created, Paid, Shipped in sequence |
| Account balance | accountId | Debits and credits in sequence |
| Chat messages | conversationId | Messages in a chat are ordered |
If all messages for orderId: 123 go to partition 7, and one consumer reads partition 7, those messages are guaranteed to be in order. Messages for orderId: 456 on partition 3 have their own independent order.
Causal ordering is a middle ground. It doesn't require a total global order. It only requires that if event B was caused by event A, then A is processed before B. Lamport timestamps and vector clocks track causal relationships without forcing everything into one partition. This is how Riak and other eventually consistent databases maintain order without a single coordinator.