Message Ordering

Controlling the sequence in which messages are delivered and processed in an event-driven system.

Message ordering is about controlling the sequence in which messages are delivered and processed. In distributed systems, the order you publish messages is not necessarily the order consumers receive them.

Consider a subscription system that publishes SubscriberSubscribed and SubscriberUnsubscribed events. If these arrive out of order, a read model built from them can end up in an incorrect state: it might try to unsubscribe someone who hasn't been subscribed yet.

The obvious solution is to order every message. But ordering everything has two serious downsides. First, performance drops because messages must be processed one by one. Second, and worse, a single failing message blocks all other messages behind it.

The practical approach is to keep ordering as narrow as possible. Instead of ordering all messages globally, order them within a small scope. For example, order events for one customer, one aggregate, or one entity. Kafka achieves this through partitions. Google Cloud Pub/Sub uses ordering keys. The idea is the same: messages that must be ordered share a key, while unrelated messages are processed independently and in parallel.

This connects to the aggregate pattern from Domain-Driven Design. An aggregate defines the smallest transactional boundary in your domain. It's often a natural fit for the ordering scope: events within one aggregate need ordering, but events across different aggregates don't.

There are cases where you can avoid ordering altogether. If each event updates a different part of the state, order doesn't matter. You can also use version numbers or timestamps to detect and handle out-of-order delivery. But these approaches require custom logic for each handler.