The Must-Know System Design Patterns

You could be asked to design almost anything: a photo feed, a ticket marketplace, a video platform, an AI agent. So how do you narrow that down to a solution in forty-five minutes, especially for a product you've never built?

The answer is that the architectures underneath these questions repeat. There are only a handful of shapes a large system can take, and experienced engineers recognize which one a problem needs before they draw a single box. In this lesson we'll cover the core patterns that underlie almost every system design question, how to tell which one applies, and what to do when a problem needs more than one.

The basic starting system

Let's start with the most basic three-tier web architecture, and then discuss how it scales and changes under different requirements. In this system, the client calls an API, a load balancer spreads those requests across a pool of stateless application servers, and those servers read and write a database that holds the truth.

This is the minimum starting shape of many systems, before we consider any specific requirements. A few properties are worth keeping as you build on it: the app tier stays stateless so you can add and remove servers freely, indexes follow the queries the product actually runs, and writes are idempotent so a retry doesn't create two orders.

What comes next depends entirely on the requirements. Reads that vastly outnumber writes push you toward caching and replicas. Data that outgrows one machine pushes you toward partitioning. Work too slow to finish inside a request pushes it into the background. Each of those requirements has a well-understood pattern that answers it, and naming the requirement before you name the solution is what separates a strong candidate from one who starts drawing boxes immediately.

The patterns you'll learn about

Each row below is a module in this course. Read the pattern lesson first, then work the mock interview breakdowns in that module, since the breakdowns assume the pattern's vocabulary.

Combining patterns

Real problems may involve combining two or more of these patterns. Here's an example.

In Design Uber Eats, the ordering path has to be correct above all else, since a double charge is a real-money failure — that's a transactional workflow. Once an order is confirmed, six different services need to know about it, and none of them should be able to block checkout — that's event-driven fan-out. Meanwhile the driver's location dot updates continuously on the customer's screen, which is a real-time system. Three patterns, three different sets of tradeoffs, one question.

The technique is to break the problem into its requirements, name the pattern each one calls for, and say which part you'd like to design first. That framing tells the interviewer you've seen the shape before, and it turns an open-ended prompt into a scoped conversation.

How to practice

Recognition is a skill you build by repetition, not by reading. Two exercises are worth doing before your interview.

Decompose prompts on paper. Take any question from the practice lists in this course and, without designing anything, write down its requirements and the pattern each one maps to. Two minutes per question. Do a dozen and the mapping starts to feel automatic, which is exactly what you want when the clock is running.

Practice the handoffs. The patterns connect in predictable ways: an event creates a job, a job writes to a partitioned store, a pipeline feeds a read model. When you finish a pattern module, pick a mock from a different module and find where the pattern you just learned shows up inside it.

Choosing a focus area

Companies ask about the problems they've actually solved. Before an interview, spend twenty minutes on what your target company's engineering blog and interview guide say they've built, and let that set your priorities.

For example, Meta tends to ask questions about products at consumer scale, so read-heavy systems and real-time messaging dominate its loops. Infrastructure-heavy companies, on the other hand, lean on distributed storage and async execution, while AI labs concentrate on agentic architectures and the serving layer underneath them, usually with a classic pattern as the foundation.

Focus on the two or three patterns that you think are most likely to be asked about, and reference our company guides if you aren't sure. If you have time to work the whole course, then go in order. The patterns build on each other, and the later ones openly reuse the earlier ones.