How does each wide-column replication model perform a conditional single-row write such as insert-if-absent, and why does its cost differ so much between them?
answer
- one owner vs many peers
- local check-then-write
- consensus among replicas
- extra round trips, contention
- every writer must play along
basics
~20 sA range-served store runs the check and the write atomically on the one server that owns the row, costing about a read plus a write. A leaderless store must run a consensus round among the row's replicas, adding several round trips and slowing under contention.
solid answer
~50 s**Range-served stores** have a single owner for each row, so a conditional write — check a cell, then mutate — is an **atomic local operation** on that server: lock the row, read, compare, write. It costs roughly a read plus a write, which is why atomic increments and check-and-mutate are routine there (within one cluster). **Leaderless stores** have no owner to serialise on, so ordinary writes cannot express "only if absent". They offer a separate **conditional write path built on a consensus protocol**: the coordinator must get a majority of the row's replicas to agree on the operation before applying it. That costs **several round trips** instead of one, serialises competing writers on the same partition, degrades sharply under contention, and only protects data if **every** writer to it uses the conditional path — a plain write can still overwrite it by timestamp. So in leaderless designs, conditional writes are kept for rare, critical cases such as uniqueness claims.
go deeper
Know that a conditional write applies a change only if a condition on the row holds, and that it is more expensive than a plain write in some stores.
Explain why a single owning server can run check-and-mutate locally and why leaderless replicas need a consensus round for the same operation.
Choose where conditional writes are worth their cost, avoid them on hot rows in leaderless stores, and catch designs that mix conditional and plain writes.
Be ready to set a team rule on when correctness claims may use consensus-based writes, and to redesign flows as immutable events to avoid them.
## The operation A **conditional write** checks a condition on a row and applies a change only if it holds: *insert this username only if it is absent*, *set status to SHIPPED only if it is PAID*. The semantics of compare-and-set and why it gives linearizable updates are general distributed-systems theory. The question here is narrower: **what does each wide-column replication model have to do to run one?** ## Range-served stores: a local atomic step In the model where each key range is served by exactly one server: 1. The request goes to the server owning the row's range. 2. The server takes a **row-level lock**, reads the current cells, evaluates the condition. 3. It applies the "true" or "false" mutations, logs them, and releases the lock. No other server holds a writable copy, so there is nothing to coordinate. The cost is close to a read plus a write on one machine, and the same mechanism gives **atomic increments** and **append** operations. Contention on one row is handled by the lock and is limited only by that server's throughput. Caveat: if the store also replicates asynchronously to other clusters, a conditional write is only meaningful against one cluster's copy — routing such requests to several clusters would let two clusters each accept a conflicting "first" write. ## Leaderless stores: a consensus round In the leaderless model, every replica accepts writes and the highest timestamp wins. That rule can express "last writer wins" but not "only the first writer wins". So these stores add a **separate conditional write path** built on a consensus protocol from the Paxos family: 1. The coordinator proposes the operation for the partition and needs **a majority of its replicas** to promise not to accept older proposals. 2. It reads the current value from a majority to evaluate the condition. 3. It asks a majority to accept the new value, then makes it visible. Implementations differ in how many phases they merge, but the operation needs **several round trips to a majority** where a plain write needs one. Consequences: - **latency** several times that of a plain write; - **contention**: competing proposals on the same partition force retries, so throughput on a hot key collapses; - **availability**: it needs a majority of replicas, whatever consistency level plain writes use; - **mixing is unsafe**: a plain write to the same cells does not go through consensus and can overwrite the result by timestamp, so every writer of that data must use the conditional path. ## Side by side | | range-served | leaderless | |---|---|---| | who decides | the single owning server | a majority of the partition's replicas | | mechanism | row lock, read, compare, write | consensus rounds, then apply | | relative cost | about a read plus a write | several round trips to a majority | | behaviour on a hot row | serialised by the lock | retries under contention | | safe to mix with plain writes? | yes, the owner serialises all writes | no, plain writes bypass consensus | ## Design guidance - In leaderless stores, use conditional writes for **rare, correctness-critical claims** (unique usernames, idempotency keys) and keep hot paths on plain writes. - Prefer designs that avoid read-before-write: write immutable events under unique keys and derive state from them. - In range-served stores, conditional writes and counters are cheap enough for normal use, but a hot row is still one server's problem. ## Interview angle The strong answer names the model first, explains why a single owner makes the operation local, explains why leaderless peers need consensus, and warns against mixing conditional and plain writes.
- Why can't a leaderless store implement insert-if-absent with its normal write path?A normal write is accepted by each replica independently and the highest timestamp wins later. Two clients can each check, see nothing, and write; both writes succeed and one silently overwrites the other. Preventing that needs the replicas to agree on an order first, which is consensus.
- How would you guarantee unique usernames in a leaderless store without using conditional writes on the hot path?Use one conditional claim per username at sign-up only, keyed by the username, and keep every later read and update on plain operations. The costly consensus round then happens once per account, not per request.
saying these in an interview costs you the question
- Assuming a conditional write costs the same as a plain write in every wide-column store
- Using conditional writes on a high-contention hot path in a leaderless store
- Mixing conditional and plain writes on the same cells and expecting the condition to hold
- Believing a read followed by a separate write is an atomic check-and-set