During a network partition that leaves fewer than R (or fewer than W) replicas reachable from a client's coordinator node, what happens to quorum reads and writes in a strict-quorum system, and how do techniques like sloppy quorums, hinted handoff, and read repair change that behavior? Also: name a case where R + W > N is satisfied yet a client can still observe stale or conflicting data.

## Why the edges matter The behavior at the edges of a quorum system is where the abstraction's real character shows up, because the R+W>N arithmetic only describes the happy path — a single write followed by a single read against a fully available cluster. Real systems spend most of their engineering effort on the paths where that assumption breaks. ## The strict answer under partition First, the straightforward partition case in a strict-quorum implementation: - If a coordinator can only reach, say, R-1 of the designated replicas for a key because a network partition has cut it off from the rest, the read simply cannot complete — there is no valid quorum to form, so the operation returns an error (often surfaced as an availability/timeout exception) rather than silently degrading to a smaller, unguaranteed quorum. - The same applies to writes when fewer than W replicas are reachable. This is an intentional design stance: the system would rather refuse to serve an operation than serve one that might violate the consistency guarantee clients rely on. It's the concrete, operational meaning of 'CP' in CAP — during a partition, you sacrifice availability (some requests fail) to preserve the consistency property (no request that does succeed violates R+W>N overlap). ## The availability-preferring alternative Sloppy quorums, covered in more depth as their own topic, are the availability-preferring alternative: instead of failing when the designated owners are unreachable, the coordinator substitutes other healthy nodes, taking on a hinted-handoff obligation to relay the data to the true owner later. This keeps the write (and often the read) succeeding through the partition, but at the cost of reintroducing exactly the staleness the strict version prevented — a subsequent read against the 'real' owners may not see the sloppy write until handoff completes, so 'is the read guaranteed fresh' quietly becomes 'the read is fresh once the system has had time to reconcile,' which is a materially different, and weaker, guarantee. Two mechanisms close this window over time: - **Read repair** — fixing stale replicas discovered during a read, by comparing the R responses and pushing the newest version to the laggards. - **Background anti-entropy** — periodic Merkle-tree-style comparison between replicas, independent of client reads. But neither is instantaneous, and a key that's rarely read and whose anti-entropy cycle hasn't run yet can sit divergent for a real, sometimes surprising, amount of time. ## Three anomalies the arithmetic never promised to prevent Even setting partitions aside entirely, R+W>N by itself is a narrower guarantee than people often assume, and the gap matters for production correctness. - **Concurrent writes** are the sharpest example: if two clients write to the same key at nearly the same time, and each write's W-sized acknowledging set only partially overlaps (or doesn't overlap at all) with the other's, the system can end up with two branches of 'the latest write' that neither branch's version metadata cleanly orders — a vector clock will show them as concurrent (neither happens-before the other) rather than one strictly newer. R+W>N guarantees a read overlaps with *a* recent write, not that there's a single unambiguous 'the' latest write when two writes race; resolving that requires an explicit policy layered on top — last-write-wins (simple, but silently drops one write), CRDTs (merge both writes structurally, e.g. a shopping cart as a set-union), or surfacing both versions to the application/client to resolve (Dynamo's original approach for conflicting versions). - **Second, partial-write visibility**: if a coordinator crashes or times out after writing to only 1 or 2 of the W required replicas (never reaching the full quorum, so the client is told the write failed or times out), those partial replicas nonetheless now hold the new value — a read whose R-sized set happens to include one of them can observe data from a write the client was never told succeeded, which is a subtle 'phantom read' surprise if the application assumed failed writes are invisible. - **Third, clock-based versioning**: if 'newest' is determined by wall-clock timestamp rather than a logical/vector clock, clock skew between nodes can cause a genuinely later write (by real-world happens-before order) to be timestamped earlier than a prior write from a node whose clock is fast, causing the read reconciliation logic to pick the wrong 'winner.' ## How it looks in production A concrete production pattern that ties this together: Cassandra clusters running at QUORUM/QUORUM (R+W>N satisfied) have still historically seen customer-visible 'flapping' values right after a burst of concurrent updates to the same row from multiple application instances, traced back to last-write-wins-by-timestamp conflict resolution combined with modest clock drift across nodes — the fix was typically to move that column to a CRDT-style counter/set type, or to route all writes for a given key through a single coordinating path to avoid true concurrency, rather than to further tune R and W (which wouldn't have helped, since the issue was concurrent-write conflict resolution, not quorum overlap).