Events Ordering
A shipment can be reported as delivered before your system has heard that it was sent. Events come from different services, through different queues, with retries in between, so the order they arrive in isn’t the order they happened in. You’ll learn how to handle that without corrupting data, how to notice that an event is missing, and where ordering can actually be guaranteed.
The first article shows how a read model can hold partial information until the missing events arrive. The second explains how to detect that something is missing when you don’t know what to expect. The third looks at putting a message back on the queue and hoping it works next time: when that helps and when it makes things worse. The last explains how message brokers group and order messages, and what that costs.
Read them in order.

Dealing with Race Conditions in Event-Driven Architecture with Read Models
2025-10-20My events came out of order! What should I do?! Are you familiar with the term “phantom record” and its benefits? No? Let me explain it to you today. Everyone has a plan…
Handling Events Coming in an Unknown Order
2025-11-03After the last article on Dealing with Race Conditions in Event-Driven Architecture with Read Models, I got such a question from Ben: You described the scenario where you…
Requeuing Roulette in Event-Driven Architecture and Messaging
2025-11-17I’m always saying that there’s a thin line between good and bad practice, and this thin line is named “Context”. That’s also true for the (anti-)pattern I’m calling…
Ordering, Grouping and Consistency in Messaging systems
2024-11-18We went quite far from our Queue Broker series in recent editions, but today, we’re back to it! Did you miss it? In an initial article, we introduced the QueueBroker—a…