Data consistency
Strong consistency: interview questions and how to answer them
Strong consistency means every read observes the most recent completed write, so the system behaves as if there were a single copy of the data.
Written and reviewed by Sahil Srivastav
What it actually is
Strong consistency — linearizability, stated precisely — means every operation appears to take effect at a single instant between its invocation and its response, and every subsequent read sees it. The system behaves as though one copy of the data existed, regardless of how many replicas actually do.
The practical consequence is the absence of a class of question. Nobody has to ask whether this read might be stale, whether a retry could see an older value, or whether two clients could observe different orders of the same events. Application code can assume the obvious thing, which is why strong consistency is worth real money where it applies.
Being precise about the terminology helps in interviews, because two different "C"s get conflated. The C in ACID is about transactions preserving invariants within one database. The C in CAP is linearizability across replicas. A single-node PostgreSQL gives you strong consistency trivially — there is one copy — while a multi-region deployment has to work for it.
Why it matters in production
Because the cost is latency and availability, and both are real rather than theoretical. To guarantee a read sees the latest write, the system must coordinate: route to a leader, or read from a quorum, or wait for replication. Coordination means at least one network round trip, and across regions that is tens to hundreds of milliseconds added to every operation that needs the guarantee.
The availability cost is sharper. If a network partition separates nodes, a strongly consistent system must refuse to serve the side that cannot establish a quorum — because serving it would risk returning stale data or accepting conflicting writes. That is a deliberate choice to return errors rather than wrong answers, and whether it is the right choice depends entirely on what the data is.
How it works
Single leader: all writes and consistent reads through one node
The simplest implementation. One node orders every write, so there is a single authority on what happened and in what order. Reads from the leader are strongly consistent; reads from followers are not, which is why read-your-own-writes breaks the moment someone routes reads to a replica for scale.
Quorums: overlapping read and write sets
With N replicas, requiring W + R > N guarantees that any read set intersects any write set, so a read always sees at least one replica carrying the latest write. This buys strong consistency without a single leader, at the cost of contacting multiple nodes on every operation — and tail latency is then set by the slowest replica in the quorum.
Consensus for ordering
Raft and Paxos exist to get a set of nodes to agree on an ordered log of operations despite failures. That agreed order is what makes linearizability possible across replicas, and it is why consensus systems require a majority to make progress — a minority cannot know it is not the stale side of a partition.
Weaker guarantees that are often sufficient
Full linearizability is frequently more than the product needs. Read-your-own-writes guarantees a client sees its own updates. Monotonic reads guarantee it never sees time move backwards. Causal consistency preserves cause-and-effect ordering. These are cheaper, and naming the specific guarantee you need is a stronger answer than demanding the strongest one.
It is per-operation, not per-system
The decision belongs to individual operations rather than to the whole database. A balance check and a stock decrement may need linearizability; a follower count, a recommendation list and an activity feed almost certainly do not. Systems that apply the strongest guarantee uniformly pay for it everywhere and usually could not justify it anywhere.
Implementing it
Decide consistency per operation by asking what a stale read would actually cost. Double-spending money is unacceptable; a follower count being three seconds old is not.
When reads are served from replicas, handle read-your-own-writes explicitly — route a user to the leader briefly after their write, or wait for the write to appear, rather than hoping replication is fast.
Prefer a conditional atomic write over a read-then-write guarded by consistency. UPDATE ... WHERE qty >= $1 enforces the invariant at the write with no coordinated read at all, which is cheaper and simpler than making the read strongly consistent.
State the staleness window where you accept weaker guarantees, and make it observable — replication lag should be a monitored metric, not an assumption.
-- Strong consistency is needed when a decision depends on the current value.
-- But the better move is usually to remove the read entirely:
-- Needs a consistent read, then a write, and a guard against interleaving.
SELECT qty FROM inventory WHERE id = $1; -- must be current
UPDATE inventory SET qty = $2 WHERE id = $1;
-- Needs neither: the condition is evaluated atomically at the write.
UPDATE inventory
SET qty = qty - $1
WHERE id = $2 AND qty >= $1;
-- 0 rows affected => insufficient stock, as a business outcome.Interview questions and how to answer them
What does strong consistency actually guarantee?
That every operation appears to take effect at a single point between invocation and response, and every later read observes it — so the system behaves as if there were one copy of the data. The practical value is that application code never has to reason about stale reads or conflicting orders.
What does it cost?
Latency and availability. Guaranteeing a read sees the latest write requires coordination — a leader hop, a quorum, or waiting for replication — which is at least one round trip, and across regions that is tens of milliseconds on every such operation. During a partition, the side without a quorum must refuse to serve rather than risk returning stale data.
Which operations in a typical product need it?
Very few, and they cluster around money and finite resources: balances, stock decrements, seat allocation, anything where two clients acting on stale data causes a real-world conflict. Feeds, counts, recommendations and search results almost never need it, and treating them as if they did makes the whole system slower for no benefit.
How do you get read-your-own-writes when reading from replicas?
Route that user's reads to the leader for a short window after their write, or track the write position and wait for the replica to reach it, or keep the written value in the session and merge it into the response. What does not work is assuming replication is fast enough — that assumption fails precisely under the load when it matters.
Is a single PostgreSQL instance strongly consistent?
Yes, trivially — there is one copy, so there is nothing to be inconsistent with. The question becomes interesting the moment you add replicas and serve reads from them, which is the point at which most teams accidentally give up the guarantee without deciding to.
Answers that lose the round
- Treating strong consistency as a system-wide setting rather than a per-operation decision
- Confusing the C in ACID with the C in CAP
- Assuming reads from a replica are strongly consistent
- Demanding linearizability where read-your-own-writes would have been sufficient and far cheaper
- Ignoring that a strongly consistent system must refuse service on the minority side of a partition
- Paying coordination cost for a read whose result is immediately overwritten by a conditional update anyway
- Claiming a system is strongly consistent without saying for which operations
FAQ
Is linearizability the same as serializability?
No, and they are frequently conflated. Serializability is about transactions appearing to execute in some serial order. Linearizability is about single operations respecting real-time ordering. A system can be serializable without being linearizable, and strict serializability is the combination of both.
Does CAP mean I must choose consistency or availability?
Only during a network partition, which is the part usually dropped. When the network is healthy you can have both. The more useful framing is PACELC: during a partition, choose availability or consistency; else, in normal operation, choose latency or consistency — and the second trade is the one you pay for every day.
Do distributed SQL databases remove the trade-off?
They make it much easier to live with, not absent. Consensus-based systems give strong consistency with good availability, but still pay coordination latency on writes, and a cross-region deployment still pays the speed of light. The trade is moved and amortised rather than eliminated.
What about caches?
A cache is an explicit decision to serve stale data, so any operation requiring strong consistency must either bypass it or use it only with a guarantee the cached value cannot be stale. Caching a balance and then deciding whether a payment can proceed is the canonical mistake.