Revision · Foundations — Why Systems Are Hard

Part 0 built the mental ruler the rest of the book measures against. Its throughline: the moment a problem outgrows one machine you inherit a network, scale, and constant failure — and every fix you reach for buys one property while charging another.

What this part covered

• Why systems are hard — a network, many copies, and ever-present failure replace one clock and one copy of truth, so “something is always broken” becomes arithmetic (N/MTBF), not pessimism.
• The recurring question — what does this buy us, and what does it cost? is the one habit to keep; “it depends” is senior because you cannot judge a design without knowing the constraint being optimized.
• The fallacies of distributed computing — the eight false assumptions (the network is reliable, latency is zero, bandwidth infinite, secure, stable topology, one admin, zero transport cost, homogeneous) cause real outages precisely because they feel true on one machine.
• Latency vs throughput — “how fast is one request” and “how many per second” are different axes, and the dominant design tension is that memory reads are orders of magnitude cheaper than network round-trips.
• The numbers to know — carrying order-of-magnitude latencies (cache ns, memory µs, disk/network ms) lets you reason about a design before writing any code.
• Back-of-the-envelope estimation — round numbers plus the three quantities you almost always need (QPS, storage, bandwidth) size a system in your head, and good estimates steer design rather than just validate it.
• Availability and the nines — an SLA/SLO/SLI are three different things, and availability multiplies down a series chain (it gets worse) while redundancy in parallel improves it.
• The CAP theorem — “pick two of three” is misleading; the real forced choice is consistency versus availability only during a network partition, and that choice shapes the whole design.

The takeaway

None of these pages is a technique to deploy — together they are a way of seeing. You now name both sides of every ledger, size a system before building it, and recognize that a partition forces a choice you cannot dodge. That lens carries directly into Part 1, where the standard building blocks are just this trade-off reasoning applied to concrete parts.