Foundations · lesson 5 of 5 · about 30 min
How to size a system in two minutes: seconds per day, requests per second and the peak, storage with copies, bandwidth and how little cache catches most reads, and how many servers. Then break it on purpose with the slips that make estimates ten times wrong. Tap any for a plain-language card.
The numbers to carry
For sizes, use powers of 1,000: KB, MB, GB, TB, PB. And remember the classic trap, : file sizes are in bytes, network speeds are in bits per second, and a byte is 8 bits. A 1 MB/s stream needs an 8 Mbps link.
Pick a volume and a size per event. The page does the divisions, and reports the peak using a .
Try 100 million events a day: about 1,160 a second on average. With a peak factor of 3, size the system for about 3,500.
1M events a day is 11.6 a second on average and 34.7 at peak. At 1 KB each that is 11.6 KB per second, or 92.6 kbps on the wire: the bytes figure times 8. Over a year it adds up to 365 GB.
Exact arithmetic: events ÷ 86,400 per second; sizes use powers of 1,000.
From users to requests
Social and content products are read-heavy (ratios of 10:1 to 100:1 are common); logging and metrics are write-heavy. State your assumption out loud: in an interview, the assumption matters more than the arithmetic, and the interviewer will correct it if it is off.
10 million users doing 10 actions a day is about 1,160 a second on average, around 3,500 at a peak of 3×. That is a handful of servers, not hundreds.
10M users × 10 actions = 100M a day, ÷ 86,400 = 1.16K/s on average. Split 10 : 1 that is 1.05K reads and 105 writes a second, and 3.16K reads and 316 writes at the 3× peak. Design for the peak figures.
Pure arithmetic from your inputs. Real traffic has daily and weekly waves; the peak factor stands in for them.
Storage
Compute it, then divide by what one machine holds to see how many you need. A useful sanity check: if the answer is a few terabytes, one database server holds it and you do not need sharding; if it is petabytes, you do.
10 million 1 KB records a day for 5 years, 3 copies: about 55 TB before overhead (82 TB with the default 50%), a handful of machines.
10M records × 1 KB = 10 GB a day. Over 5 years that is 18.3 TB; with 3 copies and 50% overhead, 82.1 TB: about 9 machines of 10 TB. A cluster, but not an exotic one.
Exact arithmetic. The 10 TB per machine is an illustrative round number.
Bandwidth and cache
The second half is a cache. Real traffic is not uniform: a few items are far more popular than the rest, a pattern called . Caching the hottest 1% of items can serve most reads. The chart is computed from the actual Zipf formula over 100,000 items (exponent 1.0 means the 2nd item is half as popular as the 1st; higher means more skewed). Memory needed = fraction cached × number of distinct items × item size.
At exponent 1.0, caching 1% of items catches about 60% of reads. At 0.6 (flatter) you would need far more.
100K reads a second × 100 KB × 8 = 80 Gbps: more than a handful of 10 Gbps network cards, so serve it from a CDN. Caching 1% of 100M items (100 GB of memory) catches 62% of reads, leaving 38.1K a second for the database.
Hit ratio is computed from Zipf weights over 100,000 items, assuming the cache holds the most popular ones. A real cache only approximates that, so treat it as an upper bound.
Servers
Two sanity numbers. Concurrent requests in flight = QPS × latency (Little's law), which sizes thread and connection pools. And the cost per request is where your real-world measurement belongs: if you can profile one request, replace the guess.
At 10,000 peak requests a second with 10 ms of CPU per request on 16-core servers, you need about eleven machines. A request that costs 100 ms instead makes it over a hundred.
16 cores ÷ 10 ms = 1.6K requests a second at 100%, so 960 at 60%. 10K peak ÷ 960 = 11 servers, 12 with a spare. At 100 ms each there are 1K requests in flight at once to hold in memory and pools.
Arithmetic on your inputs. The real figure for CPU time per request comes from profiling, not from guessing.
Put it together
Pick a system. Its starting assumptions are illustrative guesses; the point is the method. Change the user count and watch every line move. Notice how different the answers look: the URL shortener is tiny on every axis, photo sharing is a storage and bandwidth problem, chat is a request-count problem, and video is a bandwidth problem so large it needs a CDN.
Switch between the four systems and spot which row is the monster each time. That row is where the design effort goes.
Big files: storage and bandwidth dominate, not request count. Peak factor 3×, 3 copies, kept 5 years.
The monster is storage: 300 PB needs a distributed object store and tiering.
Every row is computed from the assumptions above; those assumptions are illustrative, not measured.
Which resource is the hard one?
Every system is limited by one resource more than the others, and finding which one is the whole point of estimating. Do the arithmetic, then choose. Each answer is worth 20 XP.
Compute per second (requests, bytes) and per year (storage), then see which number is absurd.
A photo app: 5 million photos uploaded a day, 2 MB each, kept 5 years, 3 copies.
Tip: press 1 to 4 to answer, Enter for the next one.
Who lives by this
Four published figures, and what each teaches about estimating.
average ≈ 5,700 tweets/s → record 143,199 tweets/s
Twitter's engineering blog (August 2013) reported that tweets averaged about 5,700 a second but a single moment during a film broadcast reached 143,199 a second: about 25 times the average. It is the best-known demonstration of why you size for the peak, not the mean.
L1 cache → RAM → SSD → disk → datacentre round trip
Jeff Dean's widely shared list of latency numbers (a main memory reference around 100 ns, a datacentre round trip around 500 µs, a disk seek around 10 ms in the original) gave engineers rough orders of magnitude to reason with. Hardware has changed; the habit of carrying the ratios has not.
uploads/minute → hours of video → storage and transcoding
YouTube has said publicly that more than 500 hours of video are uploaded every minute. A single sentence like that is enough for an estimate: 500 hours a minute is 30,000 minutes of video arriving each minute, and every file needs storing, transcoding into several formats and delivering.
uploads/week → TB/week → why a new storage system
Facebook's 2010 Haystack paper reported about 260 billion images (20 petabytes), 1 billion new photos a week (60 TB), and peak serving of about a million images a second. Estimating these numbers shows why ordinary file systems, with a disk seek for every photo, were the wrong tool.
Interview angle
Six questions, each worth 20 XP. Almost every design interview has an estimation step, and it is judged on method and sanity checks, not on exact answers.
Say each assumption aloud, round to one digit, keep units on every line, and finish by naming the dominant resource.
Roughly how many requests per second is 1 million requests a day?
Tip: press 1 to 3 to answer, Enter for the next one.
Break it
Uncertainty is the other failure: every input is a guess. If four inputs are each 90% likely to be within a factor of 2 of the truth, the product is uncertain by far more than 2×. The simulation multiplies four random inputs thousands of times to give an honest range. Treat an estimate as a range, and decide whether the decision would change anywhere inside it.
The service: 20 million users, 2 photo uploads each a day, 3 MB per photo, peak 5× the average, 3 copies, a year of storage. The correct answer is about 56 Gbps of ingress at peak. Turn the slips on and see what each does.
Switch on “Forget bits” and “Use the average” together: a 40× error that looks like a perfectly reasonable calculation.
No slips: 55.6 Gbps of ingress at peak (10 network cards) and 131 PB a year. Even then, four inputs each uncertain by 2.0× give a 90% range from 13.9 to 224 Gbps: a spread of 16×.
Ingress = users × uploads × size × 8 ÷ 86,400 × peak. The range is a seeded Monte Carlo of 8,000 draws, each input log-normally uncertain.