Consistency, CAP, and PACELC

Consistency is a promise about what a read is allowed to return. Stronger promises cost latency and availability. Name the promise a feature needs. Do not name a theorem and stop.

Models you can actually use

From strongest to weakest, the ones worth saying:

• Linearizability. Once a write completes, every later read sees it. The system behaves like one copy. This is what people want for a lock, a seat, or a balance, and it is what you give up first when you replicate asynchronously.
• Sequential and causal. Everyone sees the same order, or at least an order that respects “this read followed that write.” Useful, and hard to explain quickly. Mention them if you need them, then move on.
• Read-your-writes and monotonic reads. Session guarantees. The user who just paid sees the payment. Their feed does not jump backwards. Cheap, and enough for a lot of product work.
• Eventual. If writes stop, copies converge. They have not stopped, so say how you reconcile (last writer wins, a merge function, or a human).

CAP, briefly and correctly

A partition means some nodes cannot talk. You either refuse requests that need the missing nodes (favor consistency) or you answer with what you have (favor availability). You do not “choose partition tolerance.” On a real network you have it whether you like it or not.

Seat inventory fails closed: better to show “unavailable” than to sell one seat twice. A social feed fails open: better to show a slightly old timeline than an error page. That is the whole CAP answer for most interviews.

PACELC

CAP is silent when the network is fine. PACELC adds: else, you choose latency or consistency. Waiting for a remote replica on every write is the consistency choice. Acknowledging on the local primary is the latency choice. Async replication is that choice, made in advance.

Isolation is the single-node cousin

Inside one database, read committed (Postgres’s default) means you do not see uncommitted rows, and you can still see anomalies a serializable schedule would forbid. Serializable or an explicit SELECT … FOR UPDATE is what you want when two transactions might take the last item. Say which one. “The database is ACID” is not a concurrency-control story.

flowchart TB
  Q[Does a wrong read cost money or a double booking?]
  Q -->|yes| S[Fail closed, primary or quorum]
  Q -->|no| A[Fail open, async replica, repair later]