Skip to content

Start here

Nine editions to read first

Grouped by what you are trying to get better at. Each one links straight to the edition on Substack, where the archive lives.

Last updated:

If you want the fundamentals to actually stick

Theory that changes decisions in a design review, as opposed to the version that gets recited in interviews.

  1. The CAP Theorem Lie Everyone Keeps Repeating

    Opens with an architect claiming his distributed cache "chose CP over AP", and the follow-up question of what that meant for his SLA. The "pick two" framing survives because it fits on a slide. This works through what the theorem actually constrains.

  2. How Pinterest Serves 180M Cache Requests per Second

    Hardware-aware cache optimisation, real-time scheduling and the TLS overhead nobody budgets for. The clearest treatment in the archive of what caching costs once you are past the point where adding memory helps.

  3. What OpenAI Understood About Postgres That Most Teams Ignore

    Read-replica topology, connection management and the limits of vertical scaling on a single primary. Useful whether or not you run Postgres, because the constraints generalise.

If you want to see how large systems really work

Three systems where the public engineering detail runs deep enough to reconstruct the reasoning, including what the first design got wrong.

  1. How Discord Stores 1 Trillion Messages

    The Cassandra to ScyllaDB migration, why partition size drove the schema, and what hot partitions cost them before they solved it. The most-read edition in the archive.

  2. How Spotify Knows What You Want to Listen to Next

    Collaborative filtering, the cold-start problem, and the infrastructure that keeps recommendations fresh for hundreds of millions of listeners without recomputing the world nightly.

  3. Why AirBnB Won't Charge You Twice

    Idempotency keys done properly, with the state machine that makes a payment retry safe. If you take one practical pattern from the archive into your next design, take this one.

If you want to learn from things that broke

Two post-mortems read closely enough to follow the timeline decision by decision, and the career edition that gets forwarded most.

  1. How GitLab Lost 300GB of Production Data

    Five backup mechanisms, none of which worked, and an engineer running the wrong command on the wrong terminal at 11pm. The failure chain matters far more than the mistake at the end of it.

  2. The AWS October 20th Outage Dissection

    Fifteen hours, 113 services, one empty DNS record. A worked example of how a control-plane dependency you did not know you had becomes the thing that keeps you down.

  3. You're Not Getting Promoted Because You're Too Good At Your Job

    On becoming load-bearing for a system nobody else can operate, and why that reads as indispensable to your manager and as unpromotable to a committee.

Where do you go after these?

The full archive is on Substack and runs to 150+ editions. Premium opens all of it along with the source links for every edition. Two free reference pages live here: the 73-blog directory and the system design glossary.

Browse the full archive →