Consistency Models

Distributed-systems consistency and database isolation describe the same problem from two angles. Where consistency models talk about replicas, transaction isolation talks about concurrent transactions touching shared rows. Serializability is the gold standard: the result of running transactions concurrently is identical to some order in which they ran one at a time. No lost updates, no anomalies, no surprises. It is the transactional cousin of linearizability and it is the easiest model to reason about, which is why it is worth the cost when money or inventory is involved.

Snapshot isolation is the model most production databases actually default to, and it is the one most engineers run without realizing it. Each transaction reads from a consistent snapshot taken at its start, so reads never block writes and writes never block reads. It eliminates most anomalies but allows write skew, where two transactions each read a shared state, each decide their write is safe, and together violate an invariant that neither broke alone. Knowing that snapshot isolation is not serializable, and knowing exactly which anomaly slips through, is the difference between a system that quietly corrupts data under load and one that does not.

Underneath all of these guarantees is durability, and durability is its own set of lessons here. Write-ahead logging records the intent to change data before the data itself is touched, so a crash mid-write can be replayed or rolled back cleanly. Checkpointing and snapshotting bound how much of that log has to be replayed after a restart. Point-in-time recovery uses the log plus a base snapshot to rebuild state as it existed at any chosen moment, which is what turns an accidental mass-delete into a recoverable incident rather than a resume-updating event.

Google Spanner is the headline example of buying strong consistency at scale. It uses synchronized atomic clocks (the TrueTime API) to give external, linearizable transactions across data centers, which is why Google runs critical systems on a database that behaves like a single machine spanning continents. The price is that every commit waits out a small clock-uncertainty window. Amazon's DynamoDB takes the opposite stance by default, offering eventually consistent reads for speed and cost, with strongly consistent reads available as an explicit, more expensive option, so teams choose the guarantee per query.

Collaborative editors made these models visible to everyone. Google Docs is built on operational transformation so dozens of people can type at once and converge on the same document. Figma and many newer tools lean on CRDTs for the same reason, since CRDTs avoid the central transformation server that OT typically needs. Apple's Notes and offline-first mobile apps use CRDT-style merging so edits made on a plane reconcile cleanly when the device reconnects.

On the durability side, every serious database you have used runs the patterns in this category. PostgreSQL's write-ahead log is the source of truth for crash recovery and for streaming replication to standbys. Its base backups plus archived WAL are exactly what point-in-time recovery reads to rewind a database to the second before a bad migration. Redis offers both snapshotting (periodic point-in-time dumps) and an append-only log, letting operators trade durability against write throughput. These are not exotic features. They are the reason your data is still there after the process that wrote it crashed.