Course Introduction

1. What This Course Is About

System design looks like a huge subject. There are hundreds of technologies and thousands of possible architectures. New ones appear every year. It is hard to know where to start.

Here is the idea this course is built on. Most systems, no matter how large, are built from the same small set of recurring patterns. This course teaches 60+ of these patterns.

Once you know them, you can look at an unfamiliar architecture and recognize its parts. You can also design new systems by combining patterns you already understand. You do not have to memorize complete architectures one by one.

A pattern is not a technology. Redis is a technology. Cache-aside is a pattern: the app checks the cache first and reads the database only on a miss. A pattern is a common problem, a standard solution, and the costs that come with that solution. Technologies change every few years. Patterns stay useful for decades.

The first lesson, Thinking in Patterns, explains this idea in detail.

2. Who This Course Is For

This course is written for junior and mid-level software engineers. Data engineers and AI engineers will also benefit. Data pipelines and ML systems are distributed systems, and they use the same patterns.

You do not need any background in distributed systems. If you know what a server, a database, and an HTTP request are, you are ready. Every new term is defined the first time it appears.

3. The Twelve Modules

The course follows one running example. An online store starts with a single database and grows to a hundred million users. Each module solves the next problem the store faces as it grows.

4. How Each Lesson Works

Every pattern lesson follows the same structure:

1. The incident. Each lesson starts with a realistic production problem, with concrete numbers. A pattern is much easier to understand after you have seen the problem it solves.
2. The obvious fixes. The simple solutions most engineers try first, and why they are not enough.
3. The pattern. How it works, step by step.
4. A walkthrough with numbers. We apply the pattern to the incident and calculate the improvement.
5. Trade-offs. What the pattern costs. Every pattern has a cost.
6. When not to use it. The situations where this pattern adds complexity without enough benefit.
7. A direct comparison. How the pattern compares with its closest alternative, and how to choose between them.
8. Real-world examples. Where large companies use this pattern in production.
9. The interview angle. How interviewers test this pattern, with a 30-second answer you can practice.
10. A self-check quiz. A few questions to confirm you understood the lesson.
11. A TL;DR card. A short summary of the pattern.

The TL;DR cards from all lessons form a reference deck. Reviewing just the cards before an interview is a quick and effective way to refresh.

Lessons come in two sizes: full and compact. Simple patterns get short lessons on purpose. Each module also ends with a mini-capstone. It combines the module's patterns into one complete design.

5. This Module

Module 1 has three short lessons. They do not cover any patterns yet. They build the foundation that the rest of the course uses:

1. Thinking in Patterns: what a pattern is, and why learning patterns works better than memorizing architectures.
2. The Five Questions: five questions that turn a vague design problem into a concrete plan.
3. Back-of-the-Envelope Math: the four simple calculations this course uses again and again.

After this module, the patterns begin with the Request-Response lesson.