Every distributed system makes a consistency choice — explicitly or by accident. "Eventual consistency" gets thrown around in interviews like a magic wand, but there are at least five distinct models, each with different guarantees, latency costs, and failure modes.
When the interviewer asks "What consistency model does your design use?", you need to answer with the specific model, why it fits, and what it costs. This comparison gives you that vocabulary.
| Model | Guarantee | Latency cost | Implementation | Example systems |
|---|---|---|---|---|
| Strong consistency | All reads see the most recent write. Total order on operations. | High — requires synchronous replication or consensus | Single-leader with sync replicas, or consensus (Raft/Paxos) | Google Spanner, CockroachDB, single-node PostgreSQL |
| Eventual consistency | If no new writes, all replicas converge. No bound on when. | Lowest — async replication, local reads | Async multi-leader or leaderless replication | Cassandra (ONE), DynamoDB (default), DNS |
| Causal consistency | Causally related operations seen in order. Concurrent ops may differ. | Moderate — track causal dependencies (vector clocks) | Vector clocks, version vectors, causal broadcast | MongoDB (causal sessions), COPS, Eiger |
| Read-your-writes | A client always sees its own writes. Others may see stale data. | Low-moderate — route reads to same replica or check version | Sticky sessions, version tags, read-after-write tokens | DynamoDB (consistent reads), social media profiles |
| Linearizability | Operations appear atomic and in real-time order. Strongest guarantee. | Highest — requires coordination on every operation | Consensus protocols (Raft, Multi-Paxos, ZAB) | ZooKeeper, etcd, Spanner (with TrueTime) |
Key insight: Consistency models form a spectrum. Stronger guarantees cost more latency and reduce availability (CAP theorem). The art is picking the weakest model that your use case can tolerate — that's where you get the best performance.
Match the consistency model to the use case during your design:
The interview answer: "Strong for money. Eventual for social counters. Causal for chat. Linearizable for distributed locks."
Strong consistency means the system behaves as if there's a single copy of the data. This is what developers expect from a single-node database. In distributed systems, achieving this requires synchronous replication: every write waits for a majority of replicas to acknowledge before returning. Google Spanner achieves this globally using TrueTime (GPS + atomic clocks) for bounded clock skew.
"Eventual" sounds scary, but in practice convergence happens in milliseconds for well-tuned systems. The real risk is conflict resolution: when two replicas accept conflicting writes, you need a merge strategy (last-writer-wins, CRDTs, application-level resolution). DynamoDB uses LWW by default; Riak offered CRDTs.
Causal consistency is the strongest model achievable without coordination in a partition-tolerant system (CALM theorem). It preserves "happens-before" relationships while allowing concurrent operations to be seen in different orders by different nodes. This maps perfectly to chat: "I asked a question, you answered it" — the answer must come after the question, but unrelated messages can reorder freely.
This isn't a formal consistency model but a session guarantee that matters enormously for user experience. Implementation options: (1) route reads to the leader/same replica that handled the write, (2) include a version token in the write response and wait for the replica to catch up before reading, (3) read from cache that's updated on write.
These are often confused. Serializability is a transaction isolation level — transactions appear to execute one at a time. Linearizability is about individual operations appearing atomic and real-time ordered. Spanner provides both ("strict serializability"). Most systems provide one or neither.
Cassandra and DynamoDB let you choose consistency per query: write to 3 replicas but read from 1 (eventual), or read from 2 out of 3 (quorum = strong). The formula: W + R > N guarantees overlap between write and read sets, giving strong consistency. This per-query tuning lets you optimize hot paths independently.