Consistency Models

A sloppy quorum lets the system write to any healthy nodes it can reach instead of insisting on the exact nodes normally responsible for that piece of data. It keeps writes working during outages, but it means you can no longer be sure a later read will overlap with that write.

The '+' adds a rule for what happens when two writes conflict (weren't ordered by causality) — everyone must resolve them the same way, so replicas converge. COPS-GT is a special read path that grabs several keys' values together, so a client reading multiple related items never sees a causally inconsistent mix, like an old version of one item next to a newer, dependent version of another.

If the 'right' replicas are unreachable, the system just writes to other, reachable machines instead and promises to forward the data later. If the outage lasts too long, that promise can expire before it's kept, and the write can effectively vanish.

Instead of comparing every single record, each replica builds a tree of checksums summarizing chunks of its data. Comparing just the top checksums tells you instantly if anything differs at all, and you only dig deeper into the branches that don't match.

Strict serializability means transactions behave both as if run one at a time AND in the real order they actually happened. It's serializability plus the real-time guarantee that linearizability adds.

Every service in the chain needs to pass along a marker, like a version or vector clock entry, of what the user has already read, and the comment service must attach that marker to the write so downstream readers of the comment are forced to also be caught up on the post before they see it.

Log-based reconciliation replays a stream of changes in order to catch a replica up or keep only the newest value per key; Merkle trees compare two already-diverged snapshots to find differences after the fact. Logs are great for continuous sync, Merkle trees are the safety net for drift the log itself might have silently missed.

If you just erase a deleted record, a slightly-late update from before the delete can make it reappear, because there's nothing left to compare against. So systems keep a 'this was deleted' marker (a tombstone) around for a while instead of erasing right away — but keeping markers around forever wastes space, so they eventually get cleaned up too.

Different parts of an app need different guarantees - showing 'item in stock' can be a little stale, but charging a card exactly once needs strong guarantees. Good systems let you pick the guarantee per operation instead of one setting for everything.

Convergence isn't automatic just because updates eventually arrive everywhere — the merge rule also has to give the same result no matter what order updates show up in. CRDTs are specially designed data types built so that's always mathematically true; simpler rules like 'newest timestamp wins' can quietly lose data instead.

CRDTs make merging automatic, but the bookkeeping (unique tags, deleted-item markers, per-replica counters) keeps growing and someone has to periodically clean it up safely, which is tricky. And CRDTs are the wrong tool whenever you need a strict rule across the whole system at once, like 'account balance can never go negative,' because no replica can enforce that alone without talking to the others first.

If not enough copies are reachable, a strict system just refuses the read or write rather than risk giving a wrong answer — it picks correctness over always answering. Looser variants keep answering by writing to backup nodes and fixing things up later, but that reopens the door to occasionally seeing old or conflicting data.

Sequential consistency is theoretically cheaper than linearizability because it doesn't need to match real clock time, just one consistent story everyone agrees on. The catch: an operation that really finished earlier in time might still appear to be seen after a later one starts, as long as everyone sees the same story.

Instead of the slow write process for every read, the leader proves cheaply it's still the real leader -- one check-in with other nodes (read-index), or a time-limited promise nobody took over (lease) -- then answers locally.

Pinning every user to one region for consistency hurts latency for traveling users and makes failover harder, and comparing huge datasets nightly is expensive CPU and network work — so smart teams only pay for these guarantees on the few features where users would actually notice a violation, like their own posts, and skip them for things like view counters where nobody cares.