Wide-column stores replicate either with leaderless replicas or with one server owning each key range. What does each model give a single-row read and write?
answer
- who owns the row
- any replica vs the one server
- client picks how many answer
- strong by default in one cluster
- copies in the storage layer
basics
~20 sIn the leaderless model any replica accepts a row's writes and the client chooses how many replicas must answer, so reads can be stale. In the range-owner model one server serves each key range, so single-row reads and writes are strongly consistent by default.
solid answer
~50 s**Leaderless replicas.** Each row lives on several equal replicas; any node can coordinate a request and forward it to them, and the client chooses **how many replicas must acknowledge** a write or answer a read. Few means fast and available, but a read may miss the latest write; enough overlap gives read-after-write. Conflicting writes are settled by **cell timestamps**, and writes to one partition are applied atomically on each replica. **One server per key range.** Each contiguous key range is served by **exactly one server** at a time; durability comes from a replicated storage layer underneath (a distributed file system keeps several copies of the files and log). Because every read and write for a row goes through that one server, **single-row reads and writes are strongly consistent by default** within the cluster, and single-row read-modify-write and check-and-mutate are atomic. The cost moves to availability: when the server fails, its ranges wait for reassignment.
go deeper
Know that there are two models, many equal replicas with no leader, or one server owning each key range, and name one store-neutral difference.
Explain what a single-row read and write get in each model, who accepts the write, how fresh a read is and how concurrent writes are resolved.
Predict each model's behaviour under failure and under a hot key, and check whether application code silently assumes read-after-write.
Be ready to argue which model a system needs, availability of writes against strong single-row semantics, and what each commits operations to.
## Two answers to "who owns this row?" Replication decides who may accept a write for a row and who may answer a read. The wide-column family splits cleanly into two models, and most interview confusion comes from assuming every store works like one of them. ## Model 1: leaderless replicas - A row (more precisely, its partition) is stored on **N replicas**, all equal; there is **no leader** for it. - Any node can act as **coordinator**: it receives the request and forwards it to the replicas. - The client chooses, per request, **how many replicas must respond** before the operation counts as done — one, a majority, all. The mechanics of that choice and the overlap rule that makes reads fresh belong to consistency-level and quorum theory; here it is enough to know that the knob exists and that a low setting can return stale data. - Concurrent writes to the same cell are resolved by **timestamp** — the highest wins. - A write to one partition is applied **atomically and in isolation on each replica**, but replicas may briefly disagree with each other. - Missed writes are repaired in the background and on reads. **What a single-row operation gets:** high write availability, since any replica can take a write, and tunable freshness, but no inherent single copy of the truth. ## Model 2: one server per key range - The sorted keyspace is cut into ranges (tablets or regions), and a master assigns **each range to exactly one server** at a time. - That server alone handles every read and write for rows in its range. - **Durability does not come from the servers**: the commit log and data files live on a **replicated storage layer**, such as a distributed file system that keeps several copies. The serving server holds no unique data beyond its memory buffer, which the log protects. - Some stores add optional **read-only secondary copies** of a range that may serve slightly stale reads. **What a single-row operation gets:** because all traffic for a row funnels through one server, reads see the latest acknowledged write — **strong single-row consistency by default** — and the server can run **atomic single-row read-modify-write and check-and-mutate**. When the store also replicates to other clusters, that cross-cluster copy is usually asynchronous, so strong reads hold within one cluster. ## Side by side | | leaderless replicas | one server per key range | |---|---|---| | who accepts a write | any replica, via any coordinator | the one server serving the range | | freshness of a read | depends on how many replicas answer | latest acknowledged write, by default | | concurrent writes | timestamp decides the winner | serialised on the owning server | | conditional single-row write | a consensus round among replicas | a local atomic operation on the owner | | where copies live | on the replica nodes themselves | in the storage layer below the servers | | a server failure | other replicas keep serving | its ranges wait for reassignment | ## Why the distinction matters in design 1. **Correctness assumptions**: code that reads its own write immediately is safe by default in the range-owner model and needs the right settings in the leaderless model. 2. **Failure planning**: leaderless stores degrade by returning staler data; range-owner stores degrade by making some key ranges briefly unavailable. 3. **Hot keys**: in the range-owner model one server absorbs all traffic for a hot row; in the leaderless model the load spreads over its replicas. ## Interview angle Name the model before answering any consistency question about a wide-column store. "Strong single-row reads" is true of one model by default and a configuration choice in the other.
- If one server owns a range, how is data not lost when that server's disk fails?The server's files and commit log are written to a replicated storage layer, not to a single local disk, so several copies exist beneath it. A new server can take over the range by reading those files and replaying the log for writes not yet flushed.
- Does the leaderless model guarantee atomic multi-row writes because every replica applies partitions atomically?No. Atomicity is per partition on each replica. Rows in different partitions live on different replica sets and are written independently, so a write touching two partitions can be partly applied.
saying these in an interview costs you the question
- Assuming every wide-column store lets the client pick a consistency level per request
- Claiming range-served stores get durability by replicating each range across serving servers
- Believing leaderless stores have a primary replica that orders writes to a row
- Saying single-row reads are always strong in a leaderless store
- Assuming a range-served store's copies in other clusters keep the owning cluster's single-row guarantees