What it is
Consistency questions sit inside a larger system design and ask you to pick, for one specific piece of shared state, how strongly readers and writers must agree with each other, and what you give up to get it. The honest answer is almost never "always strongly consistent" or "always eventual" — it's naming which operation needs a hard guarantee (no double charge, no lost edit, read-your-own-write) and which can tolerate a visible lag, then choosing a mechanism (compare-and-set, a single ordered log, quorum writes, a lease) that delivers exactly the guarantee you named and nothing more expensive.
When it applies
- Two or more clients can write to, or read stale copies of, the same piece of state, and the interviewer wants to know what a reader is guaranteed to see and when.
- The system must detect or resolve a genuine conflict — two edits to the same file, two concurrent updates to the same row — rather than just serve traffic faster.
- Money, inventory, or anything where "applied twice" or "silently lost" is unacceptable is involved, which usually forces a specific mechanism (idempotency keys, compare-and-set, a majority quorum) rather than a general design principle.
- If the question is really about which storage engine or replication topology to run at all, not which guarantee one operation needs, you're one level up in
hld; consistency is the lens you apply once you already know what the write path looks like, not a replacement for designing it.
Tells in the problem
- "Must never be lost or applied twice," or an explicit ban on double-charging, double-crediting, or double-counting.
- Multiple devices or collaborators editing the same object, with a requirement to explain what happens when two edits happen "at the same time."
- A phrase like "read-your-writes," "eventually consistent is fine except for...," or "a device must see its own change immediately."
- An explicit compare-and-set, version number, or "based on version N" detail in an API description — a sign the conflict-detection mechanism is itself the deep dive.
- A tradeoff explicitly framed as availability versus correctness during a network partition or node failure.
The classic mistake
Answering with a single global label — "we'll use strong consistency" or "eventual consistency is fine" — for the whole system, instead of naming which specific operation needs which guarantee and why the rest can be weaker. This happens because "consistency model" sounds like a one-time architectural choice you declare up front, when in a real system different pieces of state (a file's own version history versus its folder listing, a wallet balance versus a merchant's daily settlement figure) legitimately need different answers. Catch it by asking, for every piece of shared state in your design, "what exactly would go wrong if a reader saw a stale value here, and how stale can it be before that matters" — a system with one answer to that question everywhere is being under-thought, not simplified.
Questions to start with
- Design a Distributed Key-Value Store — the cleanest exposition of the leader-quorum-versus-leaderless-quorum tradeoff, and the vocabulary (majority ack, read repair) the rest of this hub assumes.
- Design Cloud File Storage and Sync — conflict detection via compare-and-set on a version number, with a concrete, product-visible resolution (a conflicted copy) instead of a silent merge.
- Design a Collaborative Document Editor — the hardest version: real-time concurrent edits need an ordering mechanism (a central sequencer) rather than just picking a winner.
- Design a Payment System — where the guarantee (never double-charge) is non-negotiable and the mechanism (idempotency keys, durable state transitions) has to be exact, not just "eventually fine."