System Design

A computer whose whole job is to answer other computers. The request/response loop, demystified.

The two speed numbers that get confused constantly. One is 'how long for ME'; the other is 'how many of us per second'.

Too many people asking? Make one server bigger, or add more servers. Each choice has a catch.

Why 'the server remembers nothing about you' is secretly the trick that lets you add a hundred servers.

You have ten servers — but who decides which one answers each request? A traffic cop called a load balancer.

Keep a copy of the answer close by, so you don't redo the slow, expensive work every single time.

Finding one row by checking every row is painfully slow. An index is the page-finder at the back of a book.

Keep COPIES of your database on several machines — so if one dies your data survives, and many copies can answer readers at once.

When the data is too big for one machine, split it into pieces across many machines. The art is picking HOW to split it.

When the network between your copies breaks, you must choose: keep answering with maybe-old data, or stop until you're sure it's right. You can't have both.

Don't make the user wait for slow work. Drop a to-do note in a queue and let a worker do it later.

Stop any one user from flooding you with requests. You get N tries per minute — then you wait.

Turn a giant link into a tiny one like tinyurl — and watch every tool you learned snap into place.