0% completed
Thinking in Patterns
On This Page
- Two Candidates, One Question
- What a Pattern Is
- Patterns Combine Into Architectures
- Every Pattern Has a Cost
- How Interviews Test Patterns
- How to Study
- TL;DR
1. Two Candidates, One Question
Two candidates receive the same interview question: "Design a ride-sharing service."
The first candidate prepared by memorizing complete architectures, including the well-known Uber engineering diagrams. They can reproduce the services, the geographic index, and the connections between them accurately.
The interviewer then changes one requirement: "Let's say drivers are notified by SMS through a third-party provider that rate-limits you." The candidate cannot adapt the design because this case was not part of the architecture they memorized.
The second candidate did not memorize Uber's architecture. Instead, they examine the changed requirement and identify four familiar problems:
- A third-party provider means the call crosses a company boundary.
- A rate limit means the sender must queue messages and send them at a controlled pace.
- Delivery reports return as webhooks, which are HTTP calls the provider makes to your server. These reports may arrive more than once, so the system must handle duplicates.
- If the provider remains unavailable, the system should stop calling it temporarily and notify users inside the application instead.
The second candidate combines four patterns and states the cost of each one, so another requirement change only requires repeating the same reasoning instead of depending on a fixed diagram.
This course teaches that method. It is useful during interviews, and it remains useful at work because requirements continue to change after a system is deployed.
2. What a Pattern Is
A pattern has three parts, and a description is incomplete if any one of them is missing:
- A problem. "Instagram is slow" describes one product, not the general problem. The underlying problem is that the system recomputes the same unchanged answer thousands of times, which can happen in many different products.
- A standard solution. This is the approach experienced engineers commonly use for the problem. In this case, the system keeps a fast copy of the answer and serves that copy until the answer changes.
- A cost. The fast copy can become stale, meaning out of date, so the system needs a way to refresh it. This cost is part of the pattern rather than a separate implementation detail.
Technologies are not part of this definition. Redis, Kafka, and Postgres are tools that currently implement patterns well, while the underlying problems and solutions remain useful when the tools change.
The patterns also existed before their current software implementations. Banks used the event sourcing pattern with paper ledgers, ships used bulkheads to contain flooding, and postal services used dead letter queues for undeliverable mail.
This repetition explains why about sixty patterns can cover so much of system design. Systems may look different, but they face the same limits: networks fail, machines have finite capacity, copies of data disagree, and traffic is distributed unevenly. Because the problems repeat, the useful solutions repeat as well.
Once you understand the patterns, a new system becomes a different combination of familiar decisions rather than a completely new subject.
3. Patterns Combine Into Architectures
An architecture combines several patterns. For example, the architecture behind Netflix is not one design to memorize but roughly fifteen patterns working together. Caches reduce repeated storage reads, queues separate work between services, circuit breakers control calls to external dependencies, and replicas provide additional copies of stored data.
This changes how you approach a "design X" interview question. Instead of recalling a complete architecture, you follow three smaller steps:
- Identify the problems. Determine which known problems the system contains. A news feed has a fan-out problem, in which one post must reach many followers, and a hot-key problem, in which one item receives a large share of the traffic. A checkout flow contains payment and third-party communication problems.
- Pick a pattern for each problem. Then examine how the patterns affect one another. Retries require idempotency, which means a repeated request has the same effect as one request. Caches require a policy for expired entries. Shards require a shard key, which is the field that determines which part of the data stores a row.
- State the costs. Explain the cost introduced by each choice, and reject a pattern when the problem does not justify that cost.
Every module ends with a capstone, which is a small system design that combines the module's patterns. The final module applies the same method to four complete designs and identifies each pattern used.
4. Every Pattern Has a Cost
Every pattern is a trade. This is the most important habit taught in this course.
- A queue absorbs traffic spikes, but it adds delay and may deliver the same message more than once.
- A cache makes reads faster, but it may serve stale data.
- Sharding increases write capacity, but it makes queries across several shards harder.
- A circuit breaker ends failing calls quickly, but it may open when the dependency could still respond.
No pattern improves every part of a system. Engineering judgment requires you to understand each cost and decide whether the problem justifies it.
For this reason, every lesson includes a "When Not to Use It" section. Several lessons also explain why their pattern should not be the default choice.
The difference becomes clear in an interview. A weak answer is, "We will use Kafka here." A stronger answer is, "A queue fits here because no user waits for this work. It may deliver duplicates, so the consumer must remove them. It may also change the delivery order, which this operation does not require."
The stronger answer names the problem, the pattern, and the cost. Junior engineers learn what patterns do, while senior engineers also know what they cost and when not to use them.
5. How Interviews Test Patterns
Interviewers rarely ask you to recite definitions. They usually test your understanding in three ways:
- They watch you recognize problems. Each lesson therefore begins with an incident, which is a realistic production problem with concrete numbers. For example, if all health checks pass while one feature cannot obtain enough resources, you should consider the bulkhead pattern before the interviewer names it.
- They ask about interactions. Follow-up questions often examine how patterns affect one another: "Can your retries charge a customer twice?" or "What happens when your most popular cache key expires?" The links between lessons explain these interactions.
- They ask you to justify each choice. The question "Why not use X everywhere?" asks you to explain the costs of X. The 30-second answers in each lesson include these trade-offs because an answer without them sounds memorized.
6. How to Study
- Practice recognizing problems, not reciting definitions. When you reach the incident in a lesson, pause before reading the solution and try to identify the problem yourself.
- Learn each cost with its pattern. You should be able to explain in one sentence what a pattern provides and what it costs. The TL;DR cards support this review, and reading only those cards can refresh the main decisions before an interview.
- Practice on real systems. Choose an application you use each day and apply the five questions from the next lesson to it.
- State the costs during practice. Whenever you name a pattern in a practice interview, include its cost in the same sentence. This habit makes your reasoning explicit.
7. TL;DR
| The claim | About sixty recurring patterns underlie all of system design. Engineers who know the patterns outperform engineers who memorized architectures, because requirements change and diagrams do not. |
| A pattern is | A problem + a standard solution + a cost. All three parts, or it is incomplete. Technologies implement patterns; they do not replace them. |
| Design means | Identify the problems, pick a pattern for each, check how they interact, and state every cost out loud. |
| The senior habit | Every pattern is a trade. Knowing what it costs, and when to refuse it, is what interviews score. |
| Study by | Practicing problem recognition on the incidents, learning costs from the TL;DR cards, and never naming a pattern without its cost. |
Seif Elbayomi
· 3 months ago
A handy sheet of all cards in the course would be really helpful or at least a page collecting all of them
Reading Progress
0%
On This Page
- Two Candidates, One Question
- What a Pattern Is
- Patterns Combine Into Architectures
- Every Pattern Has a Cost
- How Interviews Test Patterns
- How to Study
- TL;DR