Consistency Models
Overview
A consistency model is the contract a distributed data store makes about when and in what order writes become visible to reads. Strong, eventual, and causal consistency are three common models that trade freshness guarantees against latency and availability.
Key Concepts
The three models sit on a spectrum from strict to relaxed:
- Strong consistency: once a write is acknowledged, every subsequent read anywhere returns that value or a newer one. It behaves as if there were a single copy of the data. This usually requires coordinating replicas before returning, which adds latency.
- Eventual consistency: replicas may temporarily disagree, but if writes stop, all replicas converge to the same value. Reads can be stale in the meantime. This model favors availability and low latency.
- Causal consistency: operations that are causally related (a reply that depends on a comment) are seen by everyone in the same order, while unrelated operations may appear in any order. It is a middle ground stronger than eventual but cheaper than strong.
The model a store can offer is bounded by the CAP theorem: strong consistency conflicts with availability during a partition, while eventual consistency embraces availability. These models are delivered through database replication, where the number of replicas a read or write must touch determines the guarantee.
| Model | Guarantee | Cost | Typical use |
|---|---|---|---|
| Strong | Reads always see the latest write | Higher latency, lower availability under partition | Balances, inventory, locks |
| Causal | Related operations seen in order | Moderate | Comment threads, collaborative edits |
| Eventual | Replicas converge over time | Stale reads possible | Feeds, view counts, DNS |
Trade-offs
Stronger consistency reduces application complexity because developers reason about a single logical copy, but it raises latency and can block reads and writes during faults. Weaker consistency keeps the system fast and available yet pushes conflict handling and staleness awareness into the application. Many stores expose a per-operation dial, so a design can request strong consistency for the few operations that need it and accept eventual consistency elsewhere.
Interview Tips
- Name the specific model per data type instead of labeling the whole system.
- Explain why strong consistency costs latency: it waits for replicas to coordinate before responding.
- Use "read-your-own-writes" as a concrete, relatable guarantee interviewers recognize.
- Mention that eventual consistency needs conflict resolution, such as last-writer-wins or version vectors.
Summary
- A consistency model defines when writes become visible to reads across replicas.
- Strong consistency always returns the latest write but costs latency and availability.
- Eventual consistency keeps the system fast and available while allowing temporary staleness.
- Causal consistency preserves the order of related operations as a practical middle ground.
- The achievable model is constrained by CAP and implemented through replication choices.