What you'll be able to design by the end

Before the work begins, the payoff. By the last module you'll design eight marquee systems end-to-end, and, far more valuable, run one repeatable method on any "design X" you're handed.

Not "I've heard of it." "I can design it."

There's a gap between recognising a system's name and being able to build it on a whiteboard from a blank start: requirements, numbers, APIs, data model, architecture, scaling, failure. This course closes that gap on the systems people actually get asked about.

Each one hangs on a signature hard part. Learn those eight hard parts and you've seen most of what real systems throw at you.

This is the shape of design you'll be able to produce and defend, boxes and arrows, by the end:

A client hits the CDN for static assets and the load balancer for everything dynamic; the API layer reads and writes through a cache and a primary store, and pushes slower work onto a queue for workers to pick up. Every one of the eight systems is a variation on this skeleton, reshaped around its own signature hard part.

Eight systems, eight signature hard parts

Each worked design in the capstone exists because of one thing it forces you to solve. The system is the vehicle; the hard part is the cargo.

Fan-out, messaging, idempotency, geospatial, CDN, dedup, indexing, contention. That list covers most of what you will ever be handed.

The goal isn't to memorise these eight

If all you leave with is eight cached solutions, you'll freeze the first time someone asks for a ninth. The eight are vehicles. What you're really extracting is the method that produced them, the one you run when there's no cached answer.

Seven steps you run on every design

The method is the same seven steps every time. What changes is the numbers and the signature hard part.

The steps run in order, but the dotted arrows are the honest part: scaling work often reshapes the architecture, and a failure mode you hadn't considered sends you back to renegotiate scope. Running the loop out loud is the skill, not marching through it once.

Every step ends in a decision, and a decision is only staff-level when it carries its price and its trigger. Written down, one step of a design looks like this:

type Step =
  | "requirements"
  | "capacity"
  | "api"
  | "data"
  | "architecture"
  | "scale"
  | "failure";

interface DesignNote {
  step: Step;
  decision: string;
  tradeOff: string;
  revisitTrigger: string;
}

const timelineFanOut: DesignNote = {
  step: "architecture",
  decision: "Fan out on write into a per-user timeline cache.",
  tradeOff: "Fast reads for everyone, expensive writes for high-follower accounts.",
  revisitTrigger: "Accounts above ~1M followers, which I'd serve by pulling at read time.",
};

That is the whole game in four fields: which step you're on, what you chose, what it cost, and what would make you change your mind. A finished design is a handful of these, in order.

The method carries you into rooms you can't rehearse

Nobody can memorise every possible "design X." But the same seven steps run on all of them, so an unfamiliar prompt stops being scary: it's the framework again, with new numbers and a new signature hard part.

And at every step you'll be making the calls lesson 0.3 talked about, naming the trade-off, picking a position, defending it. The eight systems teach the hard parts; the framework gives you a place to put every decision, out loud, in order.

Eight systems to prove it, one method to repeat it, trade-offs you can defend

1. Eight marquee systems, end to end. Twitter, WhatsApp, Stripe, Uber, YouTube, Dropbox, Google Search, Ticketmaster, each carrying one signature hard part.
2. One seven-step framework. Requirements, capacity, API, data, architecture, scale, failure, run on every design.
3. The real skill is transfer. Not the eight answers, the method that lets you handle a ninth you've never seen.
4. Next: you've finished Start Here. Module 1, lesson 1.1 · Why trade-offs are the whole game, where the six axes get mapped for real.