Back of the envelope
Five minutes of arithmetic said out loud, with one job: find the number that decides the design. Here are the numbers to carry in, the four formulas in the order to say them, and the sentence to end on.
What numbers should I memorize for a system design interview?
Two short lists. Latencies: a memory read is about 100 nanoseconds, an SSD read about 100 microseconds, a round trip inside a region about half a millisecond, a disk seek about 10 milliseconds, and a round trip across an ocean about 150 milliseconds. Capacities: an app server does around a thousand requests a second, a relational node around ten thousand simple reads, a cache node around a hundred thousand operations. Say each one as a rule of thumb, never as a measurement.
How do I turn daily active users into requests per second?
Multiply the users by what each does in a day, then divide by ten to the fifth, which is the 86,400 seconds in a day rounded up. Two hundred million users posting every other day is a hundred million posts a day, which is a thousand writes a second. Then multiply by the peak factor, two to three, and say which one you picked.
How precise should a back-of-the-envelope estimate be?
One or two significant figures. The inputs are guesses, so more digits are false precision, and they cost minutes you need later. What the interviewer grades is that each input is said, the arithmetic can be followed, and the result ends in a sentence that changes the design.
Should the estimate include replication and headroom?
Yes, both, and they are the two steps most often dropped. Every write lands on every copy, so a store with three copies sees three times the write rate. And a fleet sized exactly to the peak falls under it when one box dies: on the key-value store, thirty nodes at the line leave 38.7 thousand requests a second with one down, under a 40 thousand peak. At 70 percent headroom it takes 43 nodes.
What is Little's law, and when do I use it in an interview?
In a system that keeps up, the number of requests inside it equals the rate they arrive times the time each one spends inside. Use it to size anything that holds a request while it waits: a thread pool, a connection pool, a disk queue. Two thousand requests a second at 20 milliseconds each is 40 in flight, so a pool of 40 is exactly full and any more traffic queues.