Consistency Models for Distributed Systems Interviews: Strong, Eventual, and Causal Explained

If CAP theorem is the lightning round of distributed systems interviews, consistency models are the main event. Every staff-plus loop at Google, Meta, Stripe, Snowflake, MongoDB, Cockroach Labs, and the hyperscalers probes your ability to name a consistency model precisely and defend it against the interviewer's adversarial client.

Most candidates fail here by conflating "strong consistency," "ACID," and "linearizability" into a single mushy concept. They are not the same thing. Staff candidates know the difference, can name the guarantees each model gives the client, and — the real senior signal — can explain which one actually matches the product requirement they are being asked about.

This guide is the version of the consistency conversation I wish every candidate walked into. It assumes you know what a distributed system is. The goal is to name the models, the real-world systems that implement them, and the follow-up questions interviewers reliably ask.

The hierarchy you must memorize

Consistency is a spectrum, not a binary. From strongest to weakest, with the canonical paper for each:

• Strict consistency. Reads reflect the latest write instantaneously. Requires a global clock and is physically impossible in a distributed system. Do not claim you implement it.
• Linearizability (Herlihy & Wing, 1990). Operations appear to take effect at some instant between their invocation and response. Total order of operations; real-time ordering respected. The gold standard. etcd, ZooKeeper, Spanner reads-via-TrueTime-lease, and single-shard DynamoDB strongly consistent reads are linearizable.
• Sequential consistency (Lamport, 1979). Operations appear in some total order consistent with each process's program order, but not necessarily real time. Weaker than linearizable — a read can return a stale value if no one cared about real time.
• Causal consistency (Ahamad et al., 1995). Operations that are causally related appear in the same order on every node. Concurrent operations can be seen in different orders. COPS, Bayou, and Riak (with vector clocks) are canonical.
• Read-your-writes. A client always sees its own writes. Session-level guarantee.
• Monotonic reads. A client never sees time go backward within its session.
• Monotonic writes. A client's writes apply in order.
• Eventual consistency. If no new writes occur, all replicas will eventually converge. The weakest useful guarantee. DynamoDB default reads, Cassandra at ONE, S3 historically (strongly consistent since 2020).

Candidates who can recite this list are already above the median. Candidates who can match each to a real product earn the staff bar.

Linearizability vs. serializability — the trap

Interviewers love this distinction because candidates reliably flub it.

• Linearizability is about single-object operations and real-time order.
• Serializability is about transactions over multiple objects and logical order. A serializable system may reorder transactions freely as long as the result is equivalent to some serial order.
• Strict serializability (Papadimitriou, 1979) is the combination: transactions are serializable and also respect real-time order between non-overlapping transactions. Spanner offers strict serializability. CockroachDB offers serializable (not strict, which matters for some multi-region cases).

If you say "ACID is linearizable," the interviewer will gently correct you. ACID's I is "isolation," which usually means serializable or a weaker level (snapshot, read committed, etc.) — it says nothing about real-time order across transactions.

What interviewers actually want to hear

The senior signal is the ability to pick a consistency model from the product requirement, not the other way around.

When someone says "design an e-commerce checkout," here is the conversation that earns points:

"Inventory decrement needs linearizability — overselling is a real cost. I'd put inventory on a single-shard strongly-consistent store, probably DynamoDB with conditional writes or a Postgres row with SELECT ... FOR UPDATE. The cart contents can be causal — the user needs read-your-writes, but two devices adding different items can resolve eventually. Order history is eventually consistent from the write path, acceptable because we write once and the user tolerates a few seconds of propagation. Payment processor callbacks need exactly-once semantics on our side, which I'd solve with idempotency keys, not stronger consistency on the DB."

That paragraph demonstrates four things interviewers are scoring: correct vocabulary, matching model to subproblem, naming a real store that implements it, and knowing that "exactly-once" is a delivery problem, not a consistency problem.

The tradeoffs you need to name out loud

Every consistency choice trades availability, latency, throughput, or developer complexity. Be explicit.

• Linearizable reads cost latency. A linearizable read in Spanner requires a TrueTime wait (~7ms in practice) or a quorum read. In a Raft cluster, it requires either a read-lease or a round trip to the leader. This is why DynamoDB's strongly-consistent reads cost 2x RCUs vs. eventual.
• Cross-region linearizability is brutal. A write that must be acknowledged by a quorum across three regions pays >100ms RTT. If your product is user-facing and interactive, this is usually a non-starter outside of control-plane operations.
• Eventual consistency demands conflict resolution. If two replicas accept conflicting writes, someone has to decide which wins. LWW (last-writer-wins) is easy and occasionally wrong (clock skew). Vector clocks + application-level merge (Riak's approach) is correct and complex. CRDTs (Redis CRDTs, Riak's data types) are correct for a restricted set of data structures.
• Causal consistency is a sweet spot most architectures never reach. It's what you actually want for social feeds, collaborative docs, and chat — but implementing it requires vector clocks or hybrid logical clocks, and operationally most teams don't.
• Session guarantees are cheap wins. Read-your-writes via sticky sessions to a primary replica, or monotonic reads by pinning a client to a replica until it lags, are cheap and solve 80% of perceived inconsistency bugs.

Real-world systems and their models

Name these in the interview and you sound like someone who has read the papers:

• Spanner (Google, 2012 paper). Strict serializability via TrueTime. The only widely-deployed system that offers it across regions with bounded commit wait.
• CockroachDB. Serializable isolation, globally distributed, no TrueTime — uses hybrid logical clocks and an explicit uncertainty interval.
• DynamoDB. Single-item linearizability on strongly consistent reads, transactional writes with serializable isolation via TransactWriteItems, eventual consistency on cheap reads. Default reads are eventual — easy to miss in the interview.
• etcd and ZooKeeper. Linearizable reads and writes via Raft (etcd) and Zab (ZooKeeper). Consensus for metadata, not bulk data.
• Cassandra. Tunable — QUORUM reads + QUORUM writes with R + W > N gives you strong consistency, ONE gives you eventual. No linearizability without LWT (Paxos-backed).
• MongoDB. Linearizable reads on the primary with readConcern: linearizable, tunable otherwise. Majority write concern is common.
• S3. Strong read-after-write consistency as of December 2020 — an interview gotcha worth remembering. Pre-2020 it was eventually consistent.
• Kafka. Per-partition total order, not cross-partition. "Exactly-once" via the transactional API is actually "effectively-once" scoped to a producer-consumer pair.
• Redis with Redis Enterprise CRDTs. Eventually consistent with conflict-free merges across regions.
• Git. Causal consistency. Commits form a DAG. Merges resolve concurrent writes. A great interview analogy when explaining vector clocks.

When you should NOT push for stronger consistency

Senior candidates refuse to over-engineer. The bad cases:

• Analytics and aggregates. Dashboards, counts, trending lists — eventual is fine, seconds of lag is fine, often preferred (cheaper).
• Social feeds and notifications. Users tolerate a few seconds of propagation and never notice.
• Caches. Definitionally not authoritative. TTL + invalidation beats trying to make caches linearizable.
• Read-heavy workloads where staleness has no business cost. Product catalogs, content metadata, search indexes.
• Systems where the cost of a linearizable write is a latency budget you don't have. A mobile checkout screen that must respond in 300ms cannot wait on a cross-region quorum.

"What's the business cost of a one-second stale read?" is the question to ask out loud. If the answer is "nothing," don't reach for Spanner.

Common candidate mistakes

• Saying "strong consistency" without specifying which one. Linearizable? Serializable? Strict serializable? Say the word.
• Conflating consistency and durability. "We use RAFT so writes are consistent" — yes, and also they are durable only if the quorum survives, which is a separate property.
• Claiming exactly-once. There is no exactly-once in a distributed system — there is at-least-once delivery with idempotent handlers, which yields exactly-once semantics. Say it that way.
• Forgetting that most "ACID" databases default to read-committed, not serializable. Postgres and MySQL do. If you say "we'll use Postgres for consistency," the interviewer will ask which isolation level, and the answer matters.
• Ignoring session guarantees. A system that is eventually consistent globally can still offer read-your-writes locally. Candidates who bring this up earn points.
• Treating CAP as a three-way choice per system. It's per-request, per-operation. Spanner is CP on writes and can be AP-ish on stale reads. Name the operation.

Pseudocode: a linearizable read via quorum

# Replica-side quorum read (N=3, majority=2)
def quorum_read(key):
    responses = send_read_to_all_replicas(key, timeout=50ms)
    if len(responses) < 2:
        raise Unavailable
    # Pick the value with the highest version
    winner = max(responses, key=lambda r: r.version)
    # Read-repair: update stale replicas async
    for r in responses:
        if r.version < winner.version:
            async_write(r.replica, key, winner)
    return winner.value

Drawing this and noting "we need R + W > N for strong consistency" is a reliable points-earner in Cassandra-style questions.

Advanced follow-ups

• "How do you implement linearizable reads without going to the leader on every read?" Answer: read leases in Raft (the leader holds a lease and can serve reads for the lease duration), or ZooKeeper-style sync calls that guarantee the follower has applied all writes up to a point.
• "What's the commit protocol for a cross-shard serializable transaction?" Answer: two-phase commit with a coordinator, with Spanner-style pipelined prepare or Percolator-style locking. Know the failure modes (coordinator crash, blocked participants).
• "How does Spanner avoid clock drift breaking strict serializability?" Answer: TrueTime bounds uncertainty; writes wait out the uncertainty interval before committing. In the 2012 paper this is the commit wait.
• "How do you add linearizability to an eventually consistent system?" Answer: either add a consensus layer for specific operations (Cassandra LWT on Paxos), or accept you can't without rewriting the storage layer.
• "How do you explain the CALM theorem?" Answer: monotonic programs can be coordination-free; non-monotonic ones can't. Hellerstein and Alvaro, 2020. Rarely asked, but it's the right answer to "when can we avoid consensus entirely."
• "How does the client see the model?" Answer: through the SDK's isolation level or read concern. Document this behavior — users get surprised otherwise.

The candidates who clear a staff-plus loop on consistency are not the ones who can recite Jepsen reports from memory. They are the ones who can look at a product requirement, name the strongest model the product actually needs, and walk through which real system provides it at what latency cost. Practice narrating that chain, not the definitions.

If you can walk into a room, name linearizability and serializability as different properties, match a real store to each guarantee you choose, and explicitly state "we accept stale reads of up to N seconds on this path because the business cost is zero," you will outperform almost everyone in the candidate pool. Consistency is the hardest distributed-systems topic and the one where vocabulary precision translates directly into higher leveling outcomes.

Related guides

• Distributed Systems Interviews: CAP, Consensus & Replication — Master the core distributed systems concepts — CAP theorem, consensus algorithms, and replication strategies — that senior engineering interviews actually test.
• Designing a Rate Limiter System Design — Distributed Counters and Consistency — A system design interview guide for rate limiters: choose token buckets or sliding windows, design distributed counters, handle multi-region consistency, and plan failure behavior.
• Distributed Systems Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical distributed systems interview cheatsheet for 2026: the patterns interviewers expect, how to reason through tradeoffs, and the traps that cost strong candidates offers.
• MoSCoW Prioritization Framework for PM Interviews — Explained with Worked Examples — A PM interview guide to the MoSCoW prioritization framework with Must/Should/Could/Won’t definitions, decision rules, worked examples, traps, and interview-ready language.
• Recommender Systems Interview Guide — Collaborative Filtering, Matrix Factorization, and Two-Tower Models — A practical recommender systems interview guide covering collaborative filtering, matrix factorization, two-tower retrieval, ranking, metrics, cold start, and the traps senior interviewers look for.