Consistency and conflicts

An interview answer should say what clients may observe, what happens when replicas can't communicate, and how concurrent edits are resolved. "Strong" or "eventual" alone doesn't explain those decisions.

Write on opposite sides of a partition and watch vector clocks preserve concurrent siblings.

Compare an observed-remove set with a last-write-wins set under concurrent edits.

CAP is a partition-time choice

Suppose two regions lose contact. A write succeeds in region A, then a reader in B asks for the value. B can't know whether A changed it. Returning its local copy may violate linearizability; waiting or rejecting the read sacrifices availability for that request.

CAP's C is linearizable single-copy behavior. Its A requires every request to a non-failing node eventually receive the specified response. It's not an uptime percentage, and returning an error isn't a way to satisfy both. In a real network, partitions are possible; "choose CA and ignore partitions" doesn't specify failure behavior.

Choose per operation. A catalog view may serve stale data while disconnected; reserving the final item may require rejecting writes on a side without authority. CAP doesn't say a database must be unavailable whenever the network is healthy.

PACELC includes ordinary latency

If Partitioned, Availability or Consistency; Else, Latency or Consistency. Even on a healthy network, a region-local response can be faster than waiting for remote replicas or coordination. PACELC names that additional trade-off, rather than blaming every relaxed read on partitions. Abadi's paper introduces the distinction.

A healthy 100 ms inter-region round trip still costs time. Some operations can pay for coordination while others use weaker local reads. State each policy.

Guarantees clients can recognize

Guarantee	What it promises	What it doesn't promise
Linearizable	Each operation takes effect at one point between invocation and response, respecting real-time order	Cheap reads from arbitrary disconnected replicas
Sequential	One order consistent with each client's operation order	Respect for real-time order across clients
Causal	Effects aren't observed before the writes they depend on	One agreed order for concurrent writes
Eventual	With no new writes and successful propagation, replicas converge	A fixed staleness bound or session guarantees by itself

Read-your-writes and monotonic reads are useful session guarantees too. These models aren't interchangeable with transaction isolation: linearizable single-key reads don't by themselves make a multi-row transfer atomic.

Resolve concurrent writes deliberately

LWW usually orders timestamps with a tie-breaker; it chooses a winner rather than combining intent. A clock running ahead can dominate later writes from other machines. Don't use this rule to reconcile account debits and credits.

A version vector can show that two edits are concurrent, but the application still decides whether to ask the user, preserve both, or merge fields. A CRDT defines a safe merge mathematically. State-based CRDT merges are associative, commutative and idempotent; operation-based forms have their own delivery requirements.

Start with the product

Choose the weakest guarantee that actually meets the requirement, then explain its visible anomalies. "Likes may lag and merge; a hard spending limit uses authoritative atomic updates" is more useful than saying everything is eventually consistent.

Quick check

Quick check

Two disconnected regions must each approve purchases, but the total must never exceed one shared unallocated budget. What is missing?

AA bigger timestampBA longer TTLCA policy to coordinate approvals, reject some, or allocate separate spending rights in advanceDA last-write-wins counter

Try it

Distributed Quota Accounting HLD

Choose consistency and conflict rules for a quota whose global limit must hold during failures.