Consistency Models

Last-write-wins keeps whichever write has the newer timestamp and throws away the other one. For this to work, every replica needs a timestamp on each write, and those timestamps must be trustworthy enough to compare across machines.

Eventual consistency means all copies of data will match up eventually, but right after a write some copies might still be stale. Strong consistency means everyone sees the newest value immediately.

Convergence means all copies of the data eventually end up matching each other, even if some copies see the update late. One simple way this happens is copies periodically comparing notes and fixing whichever one has stale data.

A CRDT lets many computers update the same piece of data at the same time without talking to each other, and their copies can always be combined back into one correct answer later. A G-Counter only grows, so merging two copies means keeping the bigger count each machine reported.

Every read or write on that item behaves as if it happened instantly, at one moment, and once a write is confirmed, nobody sees an older value again.

A quorum is the minimum number of copies of your data that must respond before a read or write counts as 'done'. If the number of copies you write to plus the number you read from is bigger than the total number of copies, you're guaranteed to always read at least one copy that has the newest write.

This breaks 'read-your-writes' — after you write something, you should always be able to read it back yourself, even if other users still see stale data for a while.

A write's dependencies are every earlier write the client has read or written before making this write. The store must make sure a replica shows all of those earlier writes first, before it shows the new one — otherwise readers could see an effect without its cause.

This breaks 'read your own writes' — a client should always see its own prior actions reflected back to it. Session causality bundles that together with a few other same-client guarantees (like never seeing time move backward for yourself) so a single user's experience is always self-consistent, even if the wider system is only eventually consistent.

A vector clock is a small list of counters, one per replica, attached to a value. By comparing the lists between two versions, the system can tell if one grew directly out of the other, or if they happened independently and truly conflict.

The app doesn't guarantee 'read-your-writes' - showing your own updates back to you right after you make them. Fixes include reading from the same replica you wrote to, or checking a version marker before answering a read.

Nodes randomly pick another node every so often and compare/share their data. If one has something the other is missing, they copy it over. Repeating this many times across the cluster spreads every update everywhere without needing a central coordinator.

Hinted handoff kicks in when a replica is down during a write — another node holds onto the write and delivers it once the replica comes back. Read-repair kicks in during a read — if the replicas queried disagree, the coordinator fixes the stale one on the spot.

One kind of CRDT sends its whole current value to other computers, and they combine values together (state-based). The other kind sends just 'what changed' as a small message, applied in a way that works regardless of order (operation-based). The first tolerates lost or duplicate messages better; the second sends less data but needs more careful delivery.

Compare-and-set writes a new value only if the current value still matches what you expected. It lets many clients race to update the same item safely, because only one 'wins' at a time -- no lost updates.

Serializability makes whole transactions touching many pieces of data behave as if run one at a time, but ignores real-world timing. Linearizability keeps one piece of data instantly up to date in real time, but says nothing about multi-item transactions.

With 5 copies, writing to 3 and reading from only 2 isn't enough — 3+2 just equals 5, so the 2 you read from could be exactly the 2 that were skipped by the write. Bump the read to 3 copies and now 3+3=6 is more than 5, so the two groups must share at least one copy.

Each replica builds a tree of hashes over its data — leaves hash small chunks of data, and each parent hashes its children up to one root hash. Two replicas compare hashes top-down; matching hashes mean that whole branch is identical, so they only dig into branches whose hashes differ.

They're four separate promises to one user's session so nothing feels broken: reads won't go backward in time, you'll always see your own writes, your writes won't get reordered, and anything you read before writing will be visible to anyone who later sees that write.

When a database can't safely decide which of two conflicting writes is 'right,' it hands both versions to the application, and the application's own code — which understands what the data means — merges them into one sensible result, like combining two shopping carts instead of picking one and losing items from the other.

Last-write-wins can quietly throw away real changes when clocks disagree, when a whole record gets overwritten instead of just the changed part, or when a 'delete' loses to an older 'update.' It's still fine to use when only the newest value ever matters, like a cache or a heartbeat.

Causal consistency makes sure that if one event depends on another, like a reply on a comment, everyone sees them in that order. It doesn't force unrelated events from different users to show up in the same order for everyone.

A CRDT's merge rule has to give the same answer no matter which order you combine copies in (commutative), no matter how you group multiple merges together (associative), and merging something with itself again changes nothing (idempotent). An LWW-Register just keeps whichever write has the latest timestamp - that math works, but it means one of two concurrent writes is always thrown away, which can silently lose data.

An OR-Set tags every 'add' with a unique ID, and a 'remove' only cancels the specific adds it has actually seen. So if one replica adds an item while another replica, not knowing about that add yet, tries to remove the same-named item, the new add survives because its unique tag was never observed by that remove. A simpler design that just marks a name as 'removed forever' would wrongly block that later add too.

Linearizability needs every operation checked against a single up-to-date source of truth -- a leader or majority of replicas -- and that round trip adds delay. If unreachable, the system must refuse requests rather than risk a wrong answer.

Making reads wait on more copies makes reads slower but writes faster, and vice versa for writes. Waiting on all copies for one side makes that side slow and fragile (one down node blocks it), while the balanced middle spreads the cost evenly across reads and writes.

Because checking 'did this depend on something else' can be answered using only information the client and the local replica already have, without waiting on other machines. Anything stronger — like a single global order for all writes — needs machines to talk to each other and agree in real time, which becomes impossible if a network split cuts them off from each other.

A 'version vector' is basically the same idea as a vector clock, but it counts per storage replica instead of per client, which keeps it small and stable no matter how many different users write to the data.

A PN-Counter is really two separate 'only goes up' counters glued together - one counts all the increments, one counts all the decrements - and the real value is increments minus decrements. You can't just keep one number and take the max across replicas, because max can't tell a smaller number from 'this replica went down on purpose' versus 'this replica hasn't caught up yet.'