Back-of-Envelope Estimation for System Design Interviews: The Numbers Worth Memorizing

Five minutes into most system design rounds there's a moment where the interviewer asks how much traffic the system needs to handle, and the candidate's face does a thing I came to recognize across a lot of loops: the quiet dread of someone bracing for a math test they didn't study for. I want to make the case that this step is far less scary than it looks, partly by explaining what interviewers actually use the estimate for (I've asked the question plenty of times myself), and partly by handing over the genuinely short list of numbers and formulas involved.

What the estimate actually decides

In the design rounds I've run, I never graded whether an estimate came out right, and I don't know an interviewer who does. The estimate exists to pick which design you build. Whether the dataset fits on one machine or needs sharding, whether the workload is read heavy enough that caching does most of the carrying, whether a single primary can absorb the writes or the write path becomes the bottleneck you design around: every one of those forks depends only on the order of magnitude. Off by 2x, you land on the same fork almost every time, while off by 1000x you spend half an hour confidently building the wrong system. I made a version of this argument in my article on passing system design rounds without scale experience, and the load-bearing sentence from it is worth repeating: being off by 2x is fine, because the point is demonstrating that you can think in orders of magnitude at all.

I cook for crowds fairly often, and this is the same skill as scaling a recipe from 4 servings to 40. Nobody weighs the cumin to the gram for 40 people; you get the ratios approximately right and taste as you go. The one calculation that truly matters is the one telling you whether the regular pot will do or you need to borrow the giant one, and the interview estimate is exactly that calculation. Everything past the first significant digit is seasoning you correct while cooking.

The short list of numbers to memorize

• Seconds in a day: 86,400, rounded to 100,000 (1e5). The rounding is about 16% generous and nobody will ever care. It turns any per-day figure into a per-second figure by dropping five zeros, and it hands you a useful anchor for free: a million requests a day works out to roughly 10 a second, a number that tends to surprise people with how small it is.
• Powers of two, loosely. 2^10 is about a thousand, 2^20 about a million, 2^30 about a billion, and (the one that shows up in ID-sizing questions) 2^32 is about 4 billion, while 2^64 is infinite for any practical purpose. Treating 2^10 and 1,000 as equal costs you a 2.4% error, which is nothing at this altitude.
• Rough object sizes. A tweet-sized text record with its metadata is about 1 KB. A compressed photo, about 500 KB. A minute of decent-quality video, about 50 MB. Each is arguable by 2-3x depending on compression choices, and that's fine, because you state them as placeholders.
• Peak traffic. Multiply the daily average by 2-3x, more for genuinely spiky products like ticketing.
• Replication. Multiply stored bytes by 3 for anything you'd be sad to lose.

You can layer the classic latency numbers table on top if you like, but honestly, in nearly every estimate I've watched a candidate run, the five bullets above did all the work.

The three formulas

• QPS ≈ (DAU × actions per user per day) / 1e5
• Storage ≈ items per day × object size, times 365 for a year, times 3 for replication
• Bandwidth ≈ QPS × object size

Worked example: a feed

Take a Twitter-scale product with 200M daily active users. Assume the average user posts 0.5 times a day and reads 50 posts a day, both invented assumptions you say out loud so the interviewer can adjust them. Writes come to 100M a day, which the 1e5 trick converts to about 1,000 a second. Reads come to 10B a day, or about 100,000 a second. The individual numbers matter much less than the ratio between them: 100 reads per write says the interesting design work lives in caching and feed fanout, while the write path stays comparatively easy. That conclusion took four lines of arithmetic, and it routes the remaining half hour of the interview.

Worked example: photo storage

Say 10M photos are uploaded a day at 500 KB each. That's 5 TB a day (1e7 times 5e5 bytes is 5e12). Calling a year 400 days to keep the numbers friendly gives roughly 2 PB a year, or 6 PB once you replicate 3x. The design consequence is the real output here: data at that size lives in blob storage behind a CDN, while the metadata database stays small by comparison, since 10M rows a day at 1 KB each is 10 GB a day, a volume a single boring relational database tolerates for a surprisingly long time.

Worked example: the bandwidth gut check

Serving 100,000 tweet-sized reads a second at 1 KB each is about 100 MB a second, real but manageable for a fleet. Make the object a video stream instead and the problem transforms: 100,000 concurrent viewers at 5 Mbps each is 500 Gbps, and that one line of arithmetic is most of the reason CDNs exist. The formula never changed; the object size moved the answer by a factor of several hundred, and catching that kind of shift is the entire job of the estimation step.

Round on purpose, and narrate it

The confident move is deliberate imprecision, stated out loud. Round 86,400 up to 1e5 and say so. Call a photo half a megabyte and label it a placeholder. Announce that you'll keep one significant figure throughout. In the rounds I ran, this read as fluency, the way an experienced cook salts by eye, while the candidates who struggled were usually the ones attempting honest four-digit multiplication in their heads under observation, tangling themselves, and spending three silent minutes on arithmetic spreadsheets were invented for. If mental math with an audience makes you seize up, don't be too hard on yourself, it's common and it's fixable, and most of the fix is that aggressive rounding leaves very little arithmetic behind. Finish by sanity-checking the exponent ("a thousand tweets a second for the whole platform sounds small, but the zeros hold up, and that smallness is itself an insight about the write path") and get back to designing.

Building the reflex

Estimation responds to practice unusually fast. Pick products you already use and estimate them cold on paper (Spotify's storage footprint, Discord's message throughput, YouTube's upload bandwidth); ten of those fits in an evening and builds most of the muscle. Then run a few estimates inside full timed design rounds, out loud, because arithmetic genuinely feels different with someone watching. A friend and a whiteboard cover most of that for free, and peer mock platforms fill the gap when you don't have a willing friend. If you want the estimation step embedded in a complete timed round, with something that pushes back on your assumptions, that's part of what we built Preppable's system design mocks to do. Either way, get the reps in before the round that counts, and give yourself full permission to be off by 2x while you do.