How the tools that run the internet actually work — traced end to end.
Most documentation tells you which button to press. These guides tell you what
the machine is doing while you wait.
Here is one COMMIT, on PostgreSQL, at the resolution every guide is written at.
what COMMIT actually does
0.4msMEMORYThe row is written into a shared buffer in memory. Nothing is on disk yet.
0.4msWALA record describing the change is appended to the write-ahead log buffer.
1.8msFSYNCCOMMIT: the log buffer is flushed and fsync’d. The transaction becomes durable here — and nowhere earlier.
1.9msCLIENTOnly now is the client told it worked.
laterDISKA checkpoint finally writes the actual page into the table file.
The row reaches the table last, and the client was told “done” three steps
before that. Knowing the order is the difference between using a database and
operating one.
Start with Cassandra →13 guides · 16 chapters each · one operation traced hop by hop · a chapter arguing against every tool
The opposite bet: no leader, no failover, every node writable. The ring, the LSM tree, tombstones, compaction, quorum arithmetic, and why the data model is permanent.
The other direction entirely: columns, not rows. Sparse indexes over granules, compression that changes the economics, MergeTree, and aggregations over billions of rows in under a second.
The layer under everything above. Namespaces and cgroups, layers and copy-up, the Dockerfile line by line, a build traced through its cache, PID 1 and the ten-second stop, and volumes that survive.
Deployment with the arrow reversed. Why your CI system should not hold production credentials, sync status versus health, and the deletions that were not meant to happen.
Scheduling a graph instead of guessing at times. Why ds is not today, the top-level code that slows every installation, and the database that quietly stops keeping up.
Turning a hand-edited list of addresses into a query. Gossip that scales where heartbeats do not, and the fencing token a distributed lock is not a lock without.
Write down what the machine should look like. No agent, no server, nothing to bootstrap — and the honest answer to the charge that all this is convergent, not reproducible.
The tool that noticed your database already writes down every change it makes — and that reading that log solves a problem no amount of careful code can.
Postgres SQL and serializable transactions, spread across machines that are allowed to die. Ranges and per-range Raft, write intents, clocks that disagree on purpose, and the retry error you have to write code for.
Predictable latency bought by refusing to do anything unpredictable. Partition keys that decide everything, capacity units as the unit of thought, single-table design, and a bill that is a direct function of your access patterns.
The oldest distributed database still running, and the one every request starts with. Delegation down a tree of zones, caches that only obey themselves, a protocol still shaped by a 512-byte packet — and why nothing ever "propagates".
Each guide stands alone. Read a few together and something else appears: these
are not 59 separate subjects, they are a small number of questions
answered differently. Five databases answering what is the state of the world?
in five ways. Four proxies each doing one part of a job the others do not.