Post 03 · DDIA Ch. 5–7

Distribution

One database on many machines pretending to be one. Every trick to keep them in sync leaks — and every leak is a bug someone paged you about.

Copy the data (replication). Split the data (partitioning). Then keep concurrent users from stepping on each other (transactions). Three chapters, one problem: the fiction of a single database, defended.

Part I · DDIA Ch. 5

Replication

You updated your profile, refreshed, and it was gone. Then it came back. That's lag — the gap between a leader accepting a write and a follower catching up. Every consistency anomaly in this section is a symptom.

A follower is always some milliseconds behind the leader — sometimes microseconds under load, sometimes minutes if it's been offline. Reads from the leader see fresh data; reads from a follower may see stale data. Load-balancing reads across followers is how you scale reads, and also how you accidentally show users the wrong thing.

Three anomalies lag creates read-your-writes your own write vanishes monotonic reads time appears to move backward consistent prefix you see effects before causes

Synchronous replication: the leader waits for at least one follower to acknowledge before returning success. Zero data loss on failover, but every write pays the network round-trip and one slow follower stalls everyone. Asynchronous: the leader returns immediately and streams the write to followers in the background. Fast, but a leader crash before the flush loses committed writes. Most systems run a hybrid: one sync follower for safety, the rest async for speed.

Single-leader: one node accepts writes, everyone else follows. Simple, but the leader is a single point of failure and a bottleneck. Multi-leader: writes accepted on several nodes, replicated between them. Great for multi-datacenter, but concurrent writes to the same row need conflict resolution and no strategy is fully satisfying. Leaderless (Dynamo-style): every replica accepts writes; clients read from and write to a quorum. Uses vector clocks and read-repair to converge — powerful, but the mental model is hard.

Part II · DDIA Ch. 6

Partitioning

Replication copies the data. Partitioning splits it. And the moment you split, one customer is 30% of your traffic and one shard is on fire.

Real workloads are almost never uniform. One tenant is 30% of the traffic, one hashtag is trending, one product goes viral — and the shard holding that key gets buried while the rest sit idle. Even the best partitioning scheme can't spread a single hot key; you have to break the key itself.

Range partitioning keeps keys sorted, so range scans stay cheap — but sequential keys (timestamps, auto-increment IDs) create the classic hot-shard-at-the-end pattern. Hash partitioning spreads writes uniformly across shards — but destroys range scans, since neighbours in key-space land on different nodes. Salting is what you do for a single unavoidable hot key: prepend a small random prefix so the load spreads, and accept that reads now hit multiple shards.

The decision is driven by your query pattern, not your data. If reads are point lookups by a well-distributed key, hash. If reads are range scans over a naturally-ordered key, range. If one key concentrates traffic no matter what you do, salt it and pay the fan-out cost on reads.

Part III · DDIA Ch. 7

Transactions

Two people booked the same seat. Two on-call doctors both went off duty. A transaction is a promise — all-or-nothing, isolated from the neighbors — and every weakening of that promise is a race waiting to happen.

ACID: atomic · consistent · isolated · durable. This part is the I.

Six anomalies, from mild to career-ending: dirty reads, dirty writes, read skew, lost updates, write skew, phantoms. Every one of them is a concrete way concurrent transactions produce a state that no serial ordering could have produced. Each isolation level is a promise to prevent some of them — and to leave the others as your problem.

Every anomaly is a promise the database didn't make. Isolation levels are the rungs of stronger promises.

The isolation ladder each row lists what that level newly prevents. protections are cumulative up the ladder. Read Committed dirty read · dirty write Snapshot Iso non-repeatable read · lost updates (concurrent write conflicts)^* Serializable write skew · phantoms^† * Lost-update detection is implementation-dependent. PostgreSQL (40001), SQL Server (3960), and Oracle (ORA-08177) abort the later writer on a same-row conflict. MySQL/InnoDB's snapshot covers reads only, not writes, so read-modify-write silently loses updates unless you SELECT ... FOR UPDATE. † SI blocks phantom reads via snapshots. But write skew is a separate anomaly, and snapshots alone can't catch it (the doctors above). Vendor names for SI: PostgreSQL → REPEATABLE READ · SQL Server → SNAPSHOT · Oracle → SERIALIZABLE (SI-based; write skew still possible).

Give every transaction its own consistent view of the database as of the moment it started. Under the hood, the database keeps multiple versions of each row (MVCC) and shows each reader the versions that were committed when its snapshot began. Readers never block writers, writers never block readers, and most races just… don't happen. Write skew is the anomaly it can't catch — and that's the whole reason serializability exists.

Three routes. Actual serial execution: run one transaction at a time on a single thread (Redis, VoltDB) — fast if transactions are short and data fits in RAM. Two-phase locking: take shared locks on reads, exclusive locks on writes, hold until commit — correct, but throughput dies under contention. Serializable Snapshot Isolation (SSI): run at SI speed, track read-write dependencies, abort the loser when a conflict would produce a non-serializable outcome. SSI is the modern answer; PostgreSQL and CockroachDB use it.