Eventual Consistency

In event-driven systems, writes and reads are decoupled. This means that when a command is processed and events are produced, the read model isn't updated immediately – it updates eventually.

This is called eventual consistency.

In Our Library

Let's say a member returns a book.

• The BookReturned event is stored and published right away.
• The projection that updates the availability of that copy takes a moment to catch up.

If another member checks the catalog immediately, the system might still show the book as unavailable – just for a brief moment.

That's eventual consistency in action.

Why It's Worth It

Accepting a small delay allows the system to:

• Scale independently across read and write paths
• Avoid tight coupling and bottlenecks
• Recover and rebuild read models if needed
• Keep logic clean and composable

In return, you trade synchronous accuracy for system resilience and performance.

Designing with It in Mind

Most of the time, users don't notice the delay. But when they do, it's important to:

• Make the UI tolerant to short inconsistencies (e.g., show a "just returned" label or optimistic result)
• Avoid assumptions that the read model is always up-to-date
• Communicate actions and outcomes clearly

Eventual consistency isn't a bug – it's a conscious trade-off that enables robust, scalable systems.

Next up: Single Source of Truth – see how events unify your system's state and logic.