Eventual consistency is a consistency model where updates made to data in one part of a distributed system will propagate to all other parts over time, rather than instantly and atomically.
Key Points: • It trades immediate, strict consistency for higher availability and better performance under load, which is a common trade-off described by the CAP theorem. • In microservices, it's typically achieved through asynchronous events — when one service updates its data, it publishes an event that other services consume to update their own copies. • There is a window of time during which different services or replicas may return different (stale) results for the same piece of data. • It's well suited to systems where brief staleness is acceptable, such as product catalogs or social media feeds, but riskier for things like account balances without extra safeguards. • Patterns like the Saga pattern and CQRS commonly rely on eventual consistency to coordinate data across service boundaries.
Example: When a user updates their shipping address in the User Service, the Order Service might still show the old address for a few seconds until it processes the "AddressUpdated" event and updates its own local copy of the customer's data.
Interview Tip: A concise interview answer is:
"Eventual consistency means that after an update, the system guarantees all replicas or services will converge to the same value eventually, but not necessarily instantly. In microservices this is typically implemented through asynchronous events, and it's a deliberate trade-off for better availability and scalability compared to strict, immediate consistency."