What is system design?
System design is deciding which pieces a piece of software needs and how they talk to each other so it stays fast, correct and alive as it grows. Not the code inside each piece — the pieces themselves and the lines between them.
Here is the reassuring secret: there are only about ten pieces to know. Load balancers, caches, databases, queues, CDNs — every giant system you use daily (YouTube, WhatsApp, Uber) is these same pieces arranged for a different job. Learn what each piece does and what pain makes you reach for it, and diagrams stop looking like magic.
- component
- — one piece of the system with one job — like "the database" or "the cache"
- architecture
- — the arrangement: which components exist and how data flows between them
Words to know
The story: a pizza app grows up
You build SliceNow, a pizza-ordering app, over a weekend. One server does everything: it shows the menu, takes orders, and saves them in a database on the same machine. Ten friends use it. It is perfect.
A food blogger posts about it. Monday lunch: 2,000 people open the app at once. Your one server can handle about 500 requests per second — it starts refusing connections. Half your would-be customers see a spinning wheel and give up.
Every concept in this course is what engineers invented the day THEIR pizza app had this exact Monday.
One server handles
~500 req/sec
Monday lunch brings
~2,000 req/sec
Customers lost
most of them
Each pain summons a component
Watch how each specific pain has one specific cure — this is the whole course in five sentences.
Too many requests for one server? Run four identical servers and put a load balancer in front to spread the traffic. The menu is read 10,000 times for every 1 change? Keep a copy in a cache so the database is not asked the same question all day. Sending the receipt email makes ordering slow? Put slow work on a queue and let a background worker do it after the customer is gone. Images load slowly for users far away? A CDN keeps copies of static files near every city. One database machine can no longer hold or serve everything? Replicate it for safety and speed, shard it to split the load.
Nobody adds these pieces up front. You add each one when its pain arrives — and in an interview, naming the pain is half the answer.
The cast of characters
The pieces you will meet in this course, and the everyday job each one does.
| Component | Everyday analogy | The pain it cures |
|---|---|---|
| Load balancer | Restaurant host seating guests across tables | One server drowning while others could help |
| Cache | Sticky note with the answer you keep re-looking-up | Asking the database the same question all day |
| Database | A filing cabinet with an index | Losing data; slow searches through everything |
| Queue + worker | Restaurant order ticket rail | Making customers wait for slow back-room work |
| CDN | Local warehouses instead of one central one | Files traveling across the planet per request |
| Replicas & shards | Photocopies and split volumes of the cabinet | One cabinet too fragile or too full |
Quick check
SliceNow customers say checkout is slow. You find that saving the order takes 40ms, but sending the confirmation email takes 3 seconds. What is the right fix?
Match them up
Match each component to its job.
0/5 matched — tap a term on the left.
How to read (and draw) a system diagram
A system diagram is just boxes and arrows: boxes are components, arrows show which way requests or data flow. Read one the way you would trace a pizza order: start at the customer, follow the arrows to where the order is stored, then follow any side arrows for the extra work (emails, analytics).
When YOU draw one — and you will, in this course, by dragging components onto a canvas — always start the same way: place where the flow starts (the user) and where it must end (data safely stored), then connect the path between them one hop at a time. Side branches come last.
Good to know — There is no perfect design
Every component you add costs money, complexity, and new ways to fail. Great engineers do not use ALL the pieces — they use the fewest pieces that cure the pains they actually have. "Why is this piece here?" must always have an answer.
Quick check
In a diagram you see: Client → Load Balancer → App Server → Database, and App Server → Queue → Email Worker. A customer places an order. Which piece does the order data reach LAST on its main path?