Eventual Consistency
A model where data across services becomes consistent over time rather than immediately after a change.
Eventual consistency means that after a change is made, all parts of the system will reflect that change, but not necessarily right away. Given enough time, all parts reach the same state.
In practice, this is the trade-off you make when you move from synchronous to asynchronous communication. When a user books a ticket, the booking is confirmed immediately via HTTP. But the receipt, and the confirmation email happen asynchronously through events. For a brief moment, some parts of the system don't yet know about the booking.
This model comes from the CAP theorem: in a distributed system, you can't have consistency, availability, and partition tolerance all at once. Eventual consistency sacrifices immediate consistency for availability. Most of the time, the delay is milliseconds. But your system needs to handle the window where data is out of sync.
Eventual consistency is a design decision that makes event-driven architectures possible. The alternative (strong consistency across services) requires distributed transactions, which are slow, brittle, and hard to get right.
In practice this means your read models might sometimes be slightly outdated. An API response might not yet reflect a just-completed action. Design your UX around this.
A key skill for software engineers is being able to explain this trade-off to non-technical stakeholders, and figure out if it's acceptable for the use case at hand.
References
- Distributed Transactions in Go: Read Before You Try — Explains why eventual consistency is often a better trade-off than distributed transactions. Shows how to embrace eventual consistency with events using Watermill instead of coordinating distributed transactions across services.
- How to use basic CQRS in Go — Discusses eventual consistency as a natural consequence of separating read and write models in CQRS. When using polyglot persistence with events, eventual consistency is the key tradeoff to consider.
- Using MySQL as a Pub/Sub — Notes that eventual consistency must be acceptable in your system when using SQL databases as a Pub/Sub, since the background process publishing events may be delayed.
- Synchronous vs Asynchronous Architecture — Discusses eventual consistency as a key challenge when moving to async architecture. Covers how async systems sacrifice immediate consistency for better availability.
- Event-Driven Architecture: The Hard Parts — Covers eventual consistency as a core challenge of event-driven architecture. Discusses practical approaches to handling the consistency delay and when to embrace eventual consistency instead of distributed transactions.
