Thinking in Patterns

1. Two Candidates, One Question

Two candidates get the same interview question: "Design a ride-sharing service."

The first candidate prepared by memorizing complete architectures. They studied the well-known Uber engineering blog posts, and they reproduce the diagram accurately: the services, the geo-index, the arrows. Then the interviewer changes one requirement: "Let's say drivers are notified by SMS through a third-party provider that rate-limits you." The candidate has no answer. That case was not in the diagram they memorized.

The second candidate did not memorize Uber's architecture. They look at the new requirement and break it into problems they already know:

• A third-party provider means calls that cross a company boundary.
• A rate limit means the sender must queue messages and send them at a controlled pace.
• Delivery reports come back as webhooks, and they can arrive more than once, so duplicates must be handled.
• If the provider goes down for a long time, the system should stop calling it and notify users in-app instead.

That is four patterns, combined during the interview, with the cost of each stated. When the interviewer changes the requirement again, the second candidate simply repeats the same process.

This course trains you to be the second candidate, both in interviews and at work, where requirements change and nobody gives you a diagram.

2. What a Pattern Is

A pattern has three parts. It is only a pattern if it has all three:

1. A problem. Not "Instagram is slow," but the general problem underneath: the same unchanged answer is being recomputed thousands of times. The same problems appear in very different systems.
2. A standard solution. The approach experienced engineers use when they see this problem: keep a fast copy of the answer, and serve the copy until it changes.
3. A cost. What the solution costs you: the copy can become stale, so something must keep it fresh. The cost is part of the pattern. A pattern described without its cost is incomplete.

Notice what is not on this list: any technology. Redis, Kafka, and Postgres are tools that implement patterns well today. The patterns themselves are older and will outlast them. Banks used the event sourcing pattern with paper ledgers centuries before software existed. Ships had bulkheads before electricity. The post office had a dead letter queue before either.

This is also why about sixty patterns are enough. Systems look very different from one another, but they are all constrained by the same facts: networks fail, machines have limits, copies of data disagree, and traffic arrives unevenly. Because the constraints repeat, the solutions repeat too. Once you know the patterns, every new system is a new arrangement of parts you have already seen.

3. Patterns Combine Into Architectures

An architecture is a combination of patterns. "Netflix's architecture" is not a single thing to memorize. It is roughly fifteen patterns from this course working together: caches in front of storage, queues between services, circuit breakers around external dependencies, and replicas underneath everything.

This changes what "design X" means in an interview. It stops being a recall question and becomes three smaller steps:

1. Identify the problems. Which known problems does X contain? A news feed contains a fan-out problem and a hot-key problem. A checkout flow contains a payment problem and a third-party problem.
2. Pick a pattern for each problem. Then check how the patterns interact, because they affect each other. Retries require idempotency. Caches require a plan for what happens when entries expire. Shards require a good shard key.
3. State the costs. Say what each choice costs, and reject any pattern whose cost the problem cannot justify.

Every module in this course ends with a capstone that practices exactly this, and the final module is four complete designs built this way, annotated pattern by pattern.

4. Every Pattern Has a Cost

This is the most important habit this course teaches: every pattern is a trade.

• A queue absorbs traffic spikes, but adds delay and duplicate deliveries.
• A cache makes reads fast, but can serve stale data.
• Sharding scales writes, but makes cross-shard queries harder.
• A circuit breaker fails fast, but can trip when it should not.

No pattern simply improves a system. Engineering judgment means knowing what each pattern costs and deciding whether the problem justifies that cost. This is why every lesson in this course has a "When Not to Use It" section, and why several lessons state plainly that the default answer for their own pattern is no.

You can hear the difference in an interview. A weak answer is: "We will use Kafka here." A strong answer is: "A queue fits here because nothing waits on this work. It will cost us duplicate deliveries, so the consumer will deduplicate. It will also cost us strict ordering, which we do not need here." The second answer names the problem, the pattern, and the cost.

In one line: junior engineers learn what patterns do; senior engineers know what patterns cost, and when to say no to them.

5. How Interviews Test Patterns

Interviewers rarely ask for definitions. They test patterns in three ways:

1. They watch you recognize problems. This is why every lesson in this course starts with an incident: a realistic production problem with numbers. Recognizing the problem from its symptoms is the skill. "All dashboards are green, but one feature is starving" should make you think of the bulkhead pattern before anyone says the word.
2. They ask about interactions. Follow-up questions are usually about how patterns affect each other: "Can your retries double-charge a customer?" "What happens when your hottest cache key expires?" The cross-references between lessons in this course cover these follow-ups.
3. They ask you to justify. "Why not just use X everywhere?" is asking you to name X's costs. The 30-second answers in every lesson include the trade-offs, because an answer without trade-offs sounds memorized.

6. How to Study

1. Practice recognizing problems, not reciting definitions. When you read each lesson's incident, pause before the fix and try to name the problem yourself.
2. Learn the costs along with the patterns. For each pattern, be able to say in one sentence what it gives you and what it costs you. The TL;DR cards are built for this. Reviewing just the cards before an interview is an effective refresher.
3. Practice on real systems. Take an app you use daily and ask the five questions from the next lesson about it.
4. Say the costs out loud. In practice interviews, never name a pattern without stating its cost in the same sentence. This one habit noticeably improves how your answers sound.

7. TL;DR