Thinking in Patterns

Two Candidates

Same interview, same question: "Design a ride-sharing service."

The first candidate has prepared by memorizing architectures. They've studied the famous Uber engineering posts, and they reproduce the diagram beautifully: the services, the geo-index, the arrows. Then the interviewer changes one requirement: "Actually, let's say drivers are notified by SMS through a third-party provider that rate-limits you." The candidate freezes. That wasn't in the diagram. The map they memorized has no road here.

The second candidate never memorized Uber. They see the new requirement and think in shapes: a third-party provider means calls across a company boundary. Rate limits mean my sender must queue and pace. Delivery reports will come back as webhooks, at-least-once, so I dedupe. If the provider goes down, that's a sustained failure: stop calling, and degrade: notify in-app instead. Four patterns, composed on the spot, each with its price named. The interviewer changes the requirement again, cheerfully. It doesn't matter. The second candidate isn't recalling a map; they're navigating with a compass.

This course exists to make you the second candidate: at whiteboards, and at your actual job, where the requirements change weekly and nobody hands out diagrams.

What a Pattern Actually Is

A pattern is three things stapled together, and it's only a pattern if it has all three:

1. A problem shape. Not "Instagram is slow" but the shape underneath: the same unchanged answer is being recomputed thousands of times. Shapes recur across wildly different systems: that recurrence is the entire opportunity.
2. A standard solution. The move that experienced engineers reach for when they see the shape: keep a fast copy, serve it until it changes.
3. A price tag. What the solution costs, always: the copy can lie; someone must keep it honest. This part is not optional garnish. A "pattern" described without its price is an advertisement.

Notice what's not on the list: any technology. Redis, Kafka, and Postgres are tools that happen to implement patterns well this decade. The patterns are older and will outlive them: banks ran the event sourcing pattern with paper ledgers five centuries before software; ships had bulkheads before electricity; the post office ran a dead letter queue before either. That's why this course anchors every pattern to everyday life: not as a cute teaching trick, but because it's true: these are patterns of organizing work and information, and humans found them first.

This is also why sixtyis enough. Systems differ endlessly at the surface, but underneath they're constrained by the same few facts: networks fail, machines have limits, copies drift, and demand arrives unevenly. A small set of shapes keeps recurring because the constraints recur. Learn the shapes once, and every new system is old shapes in a new arrangement.

Composition: Architectures Are Sentences

If patterns are the vocabulary, architectures are sentences. "Netflix's architecture" isn't a thing to memorize: it's roughly sixteen patterns from this course, composed: caches in front of storage, queues between services, breakers around dependencies, replicas under everything, degradation ladders on top. The composition is the design.

This changes what "design X" means. It stops being a recall question ("do I remember the diagram for X?") and becomes three smaller, learnable moves:

• Diagnose: which problem shapes does X contain? (A feed is a fan-out shape plus a hot-key shape. Checkout is a money shape plus a boundary-crossing shape.)
• Compose: pick the pattern for each shape, and check the seams: patterns interact, and half this course's cross-references exist because retries demand idempotency, caches demand stampede plans, shards demand key choices.
• Price: say what each choice costs, out loud, and reject the patterns whose price the problem can't pay.

Every module ends with a capstone precisely to drill composition, and the final module is nothing else: four full designs, annotated pattern by pattern.

The Trade-offs Are the Content

Here's the deepest habit shift, and the one interviewers score hardest: every pattern is a purchase. A queue buys burst-absorption and sells latency and duplicates. A cache buys speed and sells truth. Sharding buys write scale and sells query flexibility. A breaker buys fast failure and sells false trips. There is no pattern that simply improves a system: there are only trades, and engineering judgment is knowing the exchange rate.

That's why every lesson in this course has a "When NOT to Use It" section, and why several lessons say bluntly that their own pattern's default answer is no. Watch the difference in how the two candidates from the opening talk: the memorizer says "we'll use Kafka here" (a technology, no price). The pattern-thinker says "a queue fits here because nobody's waiting on this work: it'll cost us duplicates, so the consumer dedupes, and ordering, which we don't need" (a shape, a price, a payment plan). One of these sentences gets hired.

The junior-to-senior arc in one line: juniors learn what patterns do; seniors know what they cost, and when to refuse them.

How Interviews Actually Test This

Almost never with definitions. Interviewers test patterns three ways, and the course's structure maps to all three:

• They watch you diagnose. Every lesson opens with an incident (a system on fire, with numbers) because recognizing the shape from symptoms is the skill: "dashboards green, one feature starved" should trigger bulkhead before anyone says the word.
• They probe the seams. The follow-up questions are nearly always about interactions: "your retries: can they double-charge?" "your cache: what happens when the hot key expires?" The cross-references between lessons are a map of these follow-ups.
• They price-check you. "Why not just use X everywhere?" is an invitation to name X's costs. The 30-second answers in every lesson are built to include the price, because an answer without trade-offs sounds memorized: and is.

How to Study, Given All That

• Rehearse diagnosis, not definitions. When you read each incident, pause before the fix and name the shape yourself. The capstones' "pause and diagnose" prompts are this, formalized.
• Collect the price tags. For each pattern, be able to say what it buys and sells in one breath. The TL;DR cards are built for this: re-reading just the cards before an interview is a legitimate strategy, not a shortcut.
• Practice composition on real things. Take an app you use daily and ask the five questions (next lesson) about it. The habit of seeing shapes in living systems is the whole game.
• Say prices out loud. In practice interviews, never name a pattern without its cost in the same sentence. It's the single highest-leverage speaking habit in system design.

TL;DR Card