Loading...
Loading...
// roadmap
System design is deciding how an app's pieces — servers, databases, caches, queues — fit together so it doesn't fall over when a million people show up instead of a hundred. One path, in order, no prerequisites assumed: 27 lessons and hands-on labs, about 3.4 hours of reading. Finish it and you'll design a real system from scratch and defend your choices out loud.
Browsing as a guest — checkmarks aren't saved.
Lesson = read · Interactive lab = build it yourself · Quiz = test yourself · Elective = optional, nothing later depends on it
Before tuning anything, you need a shared definition of what growing pains look like.
Two numbers describe every system’s performance, and beginners constantly mix them up.
When machines disagree, you must choose: answer fast or answer correctly.
Nothing loads until a name becomes an address — DNS is step zero of every request.
Some data must arrive perfectly; some must arrive now — the protocol picks the priority.
Encryption and chatty connections quietly dominate real-world latency budgets.
A traffic cop in front of your servers decides who handles each request.
Adding machines only works if any machine can serve any user.
Dumb-fast packet routing and smart content routing solve different problems.
Most of the world’s critical data still lives in tables with guarantees.
Reads are fast or slow for physical reasons — indexes and logs decide.
One database is a single point of failure; copies turn failure into a non-event.
When one machine can’t hold the data, you slice it across many.
Memory answers in microseconds what disks answer in milliseconds.
The pattern you pick decides what breaks when the cache empties at once.
Physics says distant users wait longer — so put copies near them.
Background work needs a waiting room — the shape of the room matters.
“Did it arrive once?” is three different engineering problems wearing a trench coat.
The industry’s default log — partitions decide your parallelism ceiling.
During a network split you cannot have both fresh and available — pick consciously.
A cluster needs exactly one leader — elections are how it agrees on one.
Sometimes “probably not here” answered in nanoseconds beats certainty.
Dependencies will fail — the only question is whether they take you down too.
Splitting systems buys independence — and a brand-new category of failures.
Knowing is half the interview — explaining trade-offs under pressure is the rest.
Confidence lies; scores don’t — find the gaps before an interviewer does.