Q38 — What is strong consistency — and what does it cost you?

What does strong consistency actually guarantee?

Strong consistency — more precisely called linearizability — is the strongest consistency guarantee a distributed system can offer. It means: every operation appears to take effect instantaneously at a single point in time, and once an operation completes, every subsequent read from any client on any node in the system reflects that operation's result.

In concrete terms: if you write value V to key K, and the write is acknowledged, then every read of key K that starts after the write was acknowledged will return V (or something newer if another write happened in between). No client, on any machine, at any time after the acknowledgment, can see an older value.

This is what most engineers intuitively assume databases should do — and in a single-machine database, they do. The challenge is achieving this guarantee across multiple machines.

Why is linearizability hard in a distributed system?

In a single-machine database, "all reads see the latest write" is guaranteed by the machine's memory model and the CPU's cache coherence. Reads and writes on the same machine are ordered by the hardware.

Across machines, there is no shared memory. Data exists as copies on multiple nodes. Ensuring that all copies reflect the latest state requires network communication — and networks have latency, packet loss, and partitions.

For a write to be linearizable across N nodes, every node must acknowledge the write before it's considered complete. Only then is the guarantee safe: any subsequent read from any node will find the value, because every node has it.

If even one node is slow to acknowledge, the write must wait. If a node is unreachable (partition), the write must either block (waiting for the partition to heal) or be rejected. You cannot acknowledge the write and let the unreachable node catch up later — the unreachable node might serve reads during the partition that miss the new value, violating linearizability.

This is exactly the CP side of the CAP theorem (Q39): during a partition, a linearizable system sacrifices availability to preserve consistency.

What is the practical cost of strong consistency?

Write latency is bounded below by network round-trip time to all replicas. In a single datacenter, this is 1–5ms. Across datacenters on different continents, it's 50–200ms. For every write, you pay at least one cross-replica round trip. Applications with tight write latency requirements (payment confirmation, user-facing mutations) feel this acutely.

Write availability is coupled to replica availability. If the system requires all N replicas to acknowledge a write, any unavailable replica blocks all writes. This is why most systems use a quorum (majority) rather than all replicas: requiring 3 of 5 replicas means any 2 can be down without blocking writes. But even quorum-based strong consistency blocks during a partition that leaves fewer than a quorum of replicas reachable.

Write throughput is limited by coordination overhead. Every write requires a coordination protocol — messages between nodes, responses back, decisions made. This coordination takes CPU, network bandwidth, and time. Under high write load, the coordination overhead becomes a throughput ceiling. Eventual consistency sidesteps this by not coordinating at all.

Geo-distribution becomes expensive. A global application serving users in Singapore and New York that uses strong consistency must coordinate writes across all replicas globally. A user in Singapore writing a post pays a round trip to New York (100ms+) before getting acknowledgment. This makes truly global strong consistency impractical for write-heavy applications at global scale — which is why most global distributed systems (DynamoDB, Cassandra at global scale) use eventual consistency with optional strong consistency for specific operations.

What is the difference between linearizability and serializability?

These terms are often confused, and the distinction matters.

Linearizability is a property of individual operations. It says operations on a single object (a key, a row) appear to happen at a single point in real time. It's about the ordering of single operations relative to real-world time.

Serializability is a property of transactions. It says concurrent transactions appear to have executed one at a time, in some serial order — though not necessarily in real-time order. Two transactions that ran concurrently are serializable if there's some serial order of those transactions that would have produced the same result.

Serializability is about isolation (the I in ACID — Q14). Linearizability is about ordering of individual operations across distributed nodes.

The strongest model combines both: strict serializability (also called linearizable serializability). Transactions are serialized, and their order matches real-world time. This is what Google Spanner achieves using TrueTime — GPS and atomic clocks to bound clock uncertainty — allowing it to assign globally ordered timestamps to transactions.

Most distributed databases offer one or the other, not both. CockroachDB offers serializable isolation with linearizable reads via its distributed transaction protocol. Cassandra with quorum offers linearizable single-key reads but not serializable multi-key transactions.

When is strong consistency worth the cost?

The answer depends entirely on what happens when a read returns stale data.

Financial systems: A balance read that's even 1 second stale can enable a double-spend attack (read old balance → see sufficient funds → two concurrent purchases both succeed → overdraft). Bank accounts, payment processing, and ledgers require linearizable reads.

Distributed locks: A lock that multiple processes compete for must be linearizable. If one process acquires the lock but another process reads stale state and thinks the lock is free, two processes simultaneously believe they hold an exclusive lock — correctness violation. etcd and ZooKeeper provide linearizable operations specifically to support safe distributed coordination.

Inventory management for limited items: The last seat on a flight, the last unit of a limited product, a concert ticket. If reads are stale, multiple purchasers see availability when there's one item left. Strong consistency ensures only one succeeds.

Any invariant that must be globally enforced: Unique email addresses, account limits, rate limits that must be exact. If reading stale state allows violating the invariant, strong consistency is required for that specific operation.

Configuration and coordination data: Service discovery registries, feature flag systems, election results. These are read frequently but written rarely, so the write latency cost is low. The consequence of reading stale config (connecting to a dead service, using a disabled feature) justifies the consistency cost.

How do systems implement strong consistency?

Consensus protocols: Raft (Q41) and Paxos ensure a quorum of nodes agree before any write is committed. The committed value is durable and visible to all quorum reads. Used by etcd, CockroachDB, ZooKeeper, and any system built on Raft/Paxos.

Synchronous replication: The primary waits for a majority (or all) replicas to confirm durability before acknowledging. Write is linearizable once the majority have confirmed. This is how PostgreSQL's synchronous_commit=on with synchronous_standby_names works.

Quorum reads and writes: In a leaderless system (Cassandra, DynamoDB), W + R > N ensures that at least one node in every read quorum has the latest write. Configuring W=N/2+1 and R=N/2+1 achieves strong consistency at the cost of latency equal to the slowest node in the quorum.

The mental model

Linearizability (strong consistency):
  Every operation appears instantaneous at a single point in time
  Once write is acknowledged → every subsequent read from any node sees it

Cost:
  Write latency ≥ network round trip to quorum of replicas
  Write availability: blocked if quorum unreachable (partition)
  Throughput: coordination overhead limits write rate
  Geo-distribution: every write pays cross-datacenter latency

Linearizability vs Serializability:
  Linearizability: single-operation ordering in real time (distributed systems property)
  Serializability: transaction-level ordering, as-if serial (isolation property)
  Strict serializability: both — what Spanner achieves with TrueTime

When strong consistency is worth it:
  Financial transactions, distributed locks, limited inventory, global invariants,
  coordination data (service registry, config)

When eventual consistency is fine:
  Social data, analytics, search indexes, non-critical caches, DNS

Implementation:
  Consensus (Raft/Paxos): quorum acknowledgment before commit
  Synchronous replication: primary waits for replica durability
  Quorum reads (W+R>N): read quorum always includes latest write

Strong consistency is the right default for data where "stale" means "wrong" — where reading an outdated value causes the application to take an incorrect action, violate a business invariant, or lose money. For everything else, the latency and availability costs make eventual consistency the better trade-off.