0% completed
Introduction to System Design
On This Page
What a System Design Decides
Why One Computer Stops Being Enough
The Parts a Large System Is Built From
Why Two Correct Designs Can Differ
How This Course Works
Key Takeaways
System design is the work of deciding how the parts of a software system fit together. Those parts are programs like web servers, databases, caches, and queues. The design decides which parts you use, how many of each, and how they communicate.
Here is a simple example. You build a website that lists recipes. One computer runs the website code, stores the recipes, and answers every visitor. Fifty people visit each day, and a page loads in 100 ms. There is nothing wrong with this design.
Now the site appears on the front page of a large news aggregator. Twenty thousand people arrive within one hour, and most of them arrive in the same ten minutes. The same computer must now read from disk, run the code, and send a page thousands of times per minute. Pages take 9 seconds to load, and then the site stops answering at all.
The code did not change. The load changed, and a design that was correct for 50 visitors is wrong for 20,000. System design is the work of seeing that in advance and choosing a structure that survives it.
This lesson answers three questions. What does a system design actually decide? Why does one computer stop being enough? And what will this course teach you?
What a System Design Decides
A design is a set of answers to four questions. Every topic in this course is a tool for answering one of them.
- Where does the data live? One database, several copies of it, or many machines each holding part of the data.
- How is the work spread out? One server, or many servers with something in front of them deciding who handles each request.
- What happens when a part fails? A disk dies, a network link drops, a machine restarts. The design decides whether users notice.
- What does the system promise? Every reader seeing the newest data, or fast answers that are sometimes a few seconds behind.
Notice that none of these are coding questions. They are questions about structure, and the answers are the reason two teams can build the same feature in very different ways.
Why One Computer Stops Being Enough
A server is a computer that handles requests from other computers. Its capacity is a number you can calculate.
Suppose each request needs 20 ms of processor time, and the server has 8 processor cores. Each core can finish 50 requests per second, because one second divided by 20 ms is 50. Eight cores give you about 400 requests per second, and real systems reach less than that because of disk reads and network waits.
Four hundred requests per second is a real ceiling. If your traffic grows to 2,000 requests per second, no amount of code tuning closes a gap that size. You need five servers instead of one.
That single decision creates three new problems. Something must decide which server receives each request. Something must notice when one of the five servers dies and stop sending traffic to it. And all five servers must agree about the data, because a user who saves a recipe on one server expects to see it from the next one.
This is the pattern the whole course follows. Each part you add solves one problem and creates another, and good design means knowing which trade you are making.
The Parts a Large System Is Built From
| Part | What it does | Problem it solves |
|---|---|---|
| Server | Runs your code and answers requests | Somewhere for the application to run |
| Database | Stores and organizes data permanently | Data must survive a restart |
| Load balancer | Spreads requests across many servers | One server cannot handle the traffic |
| Cache | Keeps a copy of frequently read data in memory | Reading from disk is slow and repeated |
| Content delivery network (CDN) | Serves files from machines near the user | Distance adds delay to every request |
| Partitioning | Splits one large dataset across many machines | The data no longer fits on one machine |
| Replication | Keeps copies of the same data on several machines | One failed machine must not lose the data |
| Proxy | Sits between client and server and forwards requests | A single place to filter, log, or protect traffic |
| API gateway | Gives clients one entry point to many services | Clients should not track dozens of addresses |
| Message queue | Holds work until a worker is ready for it | Slow work must not block the user's request |
You do not need to understand these yet. Each one gets its own chapter, where you learn what it does, what it costs, and when you need it.
Why Two Correct Designs Can Differ
A system design question rarely has one right answer, because different systems promise different things.
Consider a bank transfer. Every account balance must be correct the moment it is read, so the design accepts slower writes to guarantee that. Now consider the view counter on a video. If it reads 1,000,420 instead of 1,000,427, nobody is harmed, so the design accepts a few seconds of staleness in exchange for speed.
Both designs are correct for their system and wrong for the other one. This is why the reasoning matters more than the diagram. Two engineers can draw different boxes and both be right, as long as each can explain which promise their design keeps and what it gives up to keep it.
How This Course Works
The lessons are text, with a diagram wherever a picture explains more than a paragraph. Each chapter takes one part of a system and answers the same three questions about it: what problem it solves, how it works, and what it costs you.
Every topic chapter ends with a flashcard review and an adaptive assessment, so you can check what you remember before moving on. The course closes with a final quiz drawn from every chapter. You need basic programming knowledge and nothing else, and every term is defined in plain words where it first appears.
Key Takeaways
- System design decides how the parts of a system fit together, not how the code inside them is written.
- A server has a capacity you can calculate. Twenty milliseconds of processor time per request on 8 cores is about 400 requests per second.
- Every part you add solves one problem and introduces another, which is why design is a series of trades.
- The right design depends on what the system must promise. Correct balances and fast view counters call for different structures.
- You are not expected to know the parts yet. Each one is taught in its own chapter.
The next lesson starts with the first quality every design is judged by, which is scalability: the ability to handle more load by adding resources. It shows you the two ways to add those resources and what each one costs. Continue to Scalability.
Ihar Ulala
· 3 years ago
I am preparing for tech interviews and I wanted to understand the basic of sys design. My question is, should I memorise the key concept for each system (after I understand it) ? Typically I forget things if I am out of touch within just few weeks. However, I do retain it for a way longer period if the concepts have been memorised. Another thing, how long should one take to finish up this course.
Aside from that, can you guys have a feature where we can post questions in the discussion as anon and maybe allow us to rename ourselves ?
Thank you !
Reading Progress
0%
On This Page
What a System Design Decides
Why One Computer Stops Being Enough
The Parts a Large System Is Built From
Why Two Correct Designs Can Differ
How This Course Works
Key Takeaways