What system design is

You build a photo app for your friends. One small server runs the code and the database. Pages open in 50 milliseconds and nobody complains.

Then the app takes off. At 9 pm, a very large number of people open it at the same moment. Pages now take 4 seconds, the database is busy 100% of the time, and some people see errors. You did not change a single line of code; only the load changed.

Writing code that works for one person is programming. Deciding how the whole app keeps working for millions of people is system design. This course teaches it one small idea at a time.

What system design is

System design is deciding three things:

1. The parts. Which pieces the system has: app servers, databases, caches, queues and so on.
2. How they talk. The requests and messages that flow between those parts, usually through an API.
3. Where data lives. Which store keeps what, and how many copies exist.

You choose them so the system meets its requirements (what it must do, how fast, how reliably) at its load (how many people, how often). Then you check the choice with numbers.

The parts you will meet

Big apps are built from a small set of parts. Each one has one job, and each has its own lesson later in this course.

Part	Its job	Learn it in
Client (phone app, browser)	Sends requests and shows the results	This lesson
DNS	Turns a name like example.com into a server address	Lesson 13
CDN	Serves photos and files from a server near you	Lesson 14
Load balancer	Spreads requests over many app servers	Lesson 15
App servers	Run your code for each request	Lesson 19
Cache	Keeps hot data in memory so it is fast to read	Lesson 33
Database	Keeps data safely on disk	Lesson 21
Queue	Holds slow work so it can run in the background	Lesson 39

Follow one request

Here is what happens when you open the photo app at 9 pm:

1. The phone asks DNS for the server's address.
2. Photos come from a CDN server close to you, so they do not cross the world.
3. The request for your feed goes to the load balancer.
4. The load balancer hands it to whichever app server is free.
5. The app server reads hot data from the cache, and anything else from the database.
6. Slow work, like resizing a new photo, goes on a queue and a worker does it later, so you never wait for it.

So the 9 pm fix has a clear shape: more app servers behind the load balancer, a cache in front of the database, and photos on a CDN. Which of these you need, and how many, depends on the numbers, and the five steps below are how you get them.

The five steps

Every design in this course, from a like button to a video service, follows the same five steps.

1. Requirements. What must the app do, and how well? For example: "show the 20 newest posts from people you follow, quickly, even at peak".
2. Estimates. How many users, how many requests a second, how much data. Rough is fine as long as the order of size is right.
3. API and data. The requests the app sends, and the tables or records you store.
4. The design. The parts and arrows from the picture above, chosen for this load.
5. Check and measure. Work out what each part must handle, find the part that breaks first, and test it.

The five steps on a real feed

Take a photo feed, the screen you see when you open the app.

Step 1, requirements. Show the 20 newest posts from the accounts you follow. Each person follows about 150 accounts.

Step 2, estimates. Say the app has 100 million daily users who open the feed 10 times a day. That is 1 billion opens a day, or about 11,600 a second on average. The evening peak is about 3 times higher:

100,000,000 users × 10 opens ÷ 86,400 seconds × 3 ≈ 35,000 feed opens a second

Step 3, API and data. One request, GET /feed?cursor=…, returns 20 posts. Two tables are enough to start: posts (id, author, time) and follows (who follows whom).

Step 4, the design. There are two ways to build a feed:

• Build it when it is opened. Read the newest posts of all 150 accounts you follow, then merge them.
• Build it when someone posts. When an account posts, add the post to the stored feed of each follower. Opening the feed is then one read.

Step 5, check with numbers. Building on open costs 150 reads per open: 150 × 35,000 = 5,250,000 reads a second. Building on post costs one write per follower. About 347 posts arrive a second, each going to about 150 followers, so roughly 52,000 writes a second, plus one read per open (35,000 a second): about 87,000 operations in total. For normal accounts the second way is about 60 times less work. Accounts with tens of millions of followers are the exception: one post would mean millions of writes at once, so their posts are merged in when the feed is opened.

Summary

• System design is choosing the parts, how they talk and where data lives, so an app keeps working at its real load.
• Every big app uses the same few parts: load balancers, app servers, caches, databases, queues, CDNs and DNS. Each has one job.
• The five steps (requirements, estimates, API and data, the design, check and measure) keep the numbers in charge. In the feed example, two multiplications showed which design was about 60 times cheaper.

In the next lesson you will practise steps 1 and 2 properly: writing requirements you can measure, and turning daily users into requests a second, storage and servers.