System Design Concepts

Why using one relational database for everything breaks down as an app grows — and how polyglot persistence fixes it.

During a network partition, a distributed system can guarantee at most two of Consistency, Availability, and Partition Tolerance.

CAP only describes what happens during a partition — PACELC covers the trade-off a system faces the rest of the time.

Cache-Aside, Write-Through, and Write-Behind — three different answers to who updates the cache, and when.

Leader-follower, multi-leader, and leaderless replication — three different answers to how copies of the same data stay in sync.

Hash-based, range-based, and directory-based sharding — three ways to decide which shard a row actually lives on.

Two-Phase Commit and the Saga pattern — two very different ways to keep a transaction consistent across multiple services or shards.

How Raft and Paxos let distributed nodes agree on a single value — like who's the leader — despite failures.

Writing to a database and a cache as two separate steps looks fine — until the process crashes between them.

A worked architecture where every choice this journey has covered gets picked for one reason: money cannot silently disappear or duplicate.

The opposite problem from a payment system: correctness matters less here than surviving a write volume that would crush a relational database.

One platform, two completely different consistency requirements: inventory can never lie, and search can lag by seconds without anyone noticing.

A hundred thousand sensors reporting once a second don't care whether your database is ready for them.

56 chapters of trade-offs, distilled into the four questions that actually decide which storage system belongs in your architecture.