Lesson 01 · System Design
Two billion people. Every minute. Sending photos, voice notes, terrible memes. And somehow… it just works.
When an app is small, this is all you need. The server cooks. The database remembers. Life is good. Nobody is crying yet.
One server. A million requests. It starts sweating. Then catches fire. Then sends you a 3 AM Slack ping. This is the problem system design exists to solve.
A tiny sitcom of computers. Learn what each one does and you can architect almost anything. Tap any to peek at its glossary card — try and too.
You tap "send." A tiny packet of data sets off on a tour through the system, stopping at each character along the way.
A is a sticky-note the server keeps. If the answer is on the note — instant reply. If not, it has to ask the database (slow).
Drag the slider. Watch the server start sweating — then a load balancer shows up and the work gets shared. New word? Tap .
Calm. One server is plenty.
Reads are fast. Writes are crawling. Every request waits on a single -y component. Tap the suspect.
Every system design decision is a tug-of-war between these four. You can't maximize all of them — you trade.
Recap
You now know the cast, the journey of a request, and the four forces. From here on, every lesson zooms into one piece of this picture.
— end of lesson 01 —