What is eventual consistency, and when is it acceptable?
Quick Answer
Eventual consistency means after a change, different parts of the system converge to the same value eventually, but there's a window where they disagree (a replica lags, an event hasn't been processed). It's acceptable when the business can tolerate a short staleness window — a follower count, a search index — and unacceptable for things like an account balance at the moment of a withdrawal.
Eventual consistency is when a write doesn't immediately show up everywhere — a read replica is a few seconds behind, or an event that updates a projection hasn't been processed yet — but everything catches up shortly. It's fine for a lot of things: a like count, a recommendation, a dashboard that's a minute stale. It's not fine where correctness at that instant matters, like checking a balance before allowing a withdrawal — that needs to be strongly consistent within one transaction. Common mitigations are routing a user's own reads to the primary right after they write, and optimistic UI so it feels instant.
- The CAP theorem: under a network partition you choose availability (serve possibly-stale data) or consistency (refuse).
- Mitigations: “read your own writes” (route a user's reads to the primary right after their write), show optimistic UI, use versioning to detect conflicts.
- For invariants that must hold, keep them in one transaction/aggregate; use compensating actions (a saga) across services.