What numbers should I memorise for back-of-the-envelope estimation?

Six things carry almost every round. There are 100,000 seconds in a day, which is 86,400 rounded up. One million requests a day is about 10 queries per second. A metadata row is about 100 bytes and a compressed web photo about 300 kilobytes. One kilobyte per second is about 30 gigabytes a year. Main memory is 100 nanoseconds while a same-datacentre round trip is 500 microseconds. Everything else derives from those.

How do you convert DAU into QPS in a system design interview?

Multiply daily active users by actions per user per day, then divide by 100,000, the rounded number of seconds in a day. Five hundred million users opening a feed ten times a day gives five billion requests, which is 50,000 queries per second on average. Multiply by three for peak. Say the rounding out loud, because using 100,000 instead of 86,400 makes your answer about 15 percent low.

How much storage does a photo-sharing app need per year?

At 50 million uploads a day and 2 megabytes stored per photo including thumbnails and web-size derivatives, that is 100 terabytes a day and roughly 40 petabytes a year before replication. The metadata is trivial by comparison, about 15 gigabytes a day at 300 bytes a row. The gap between those two figures is the whole reason photos live in object storage behind a CDN and never inside the database.

How do I round aggressively in an interview without sounding sloppy?

Name the precision you need before you calculate. Say you only need to know whether this is one server or a thousand, so a factor of two either way does not change the answer. Then round to one significant figure, say which direction the error runs, and round the numerator and denominator in opposite directions so the errors partly cancel. Stating the error is what separates deliberate from careless.

Does a URL shortener need sharding?

Not for capacity. One million new links a day at about 200 bytes a row is 200 megabytes a day, roughly 70 gigabytes a year, so ten years of links fits on a single disk. Base62 with seven characters gives about 3.5 trillion keys, thousands of years of supply at that rate. You shard a shortener for availability and geographic latency, not because the data is large.

What limits how many chat connections one server can hold?

Memory per open socket, mostly, plus whatever per-connection state your application keeps. A tuned server holds somewhere between 100,000 and one million idle connections depending on buffer sizes, so quote a range rather than a single figure and say why it is a range. At 100 million concurrent users and 250,000 per box you need about 400 connection servers, which is why the connection layer is separated from business logic.

Back-of-the-Envelope Estimation for System Design Interviews

Memorise six things and every estimation in a system design round becomes arithmetic you can do out loud. There are 100,000 seconds in a day (86,400, rounded up). One million events a day is about 10 per second. A metadata row is 100 bytes, a web-size photo 300 KB, a chat message 250 bytes. One KB per second is 30 GB a year. Memory is 100 ns, an SSD read 100 µs, a same-datacentre round trip 0.5 ms, a cross-continent one 150 ms. Peak is 3× average unless you have a reason to say otherwise. Below: the full table, three designs estimated longhand in under two minutes each, and how to round hard without sounding like you are guessing.

The whole table, one screen

You are not being tested on arithmetic. You are being tested on whether you can turn a product statement into a number that forces an architectural decision, in about ninety seconds, while talking. These are the inputs.

Quantity	Memorise as	Where it comes from
Seconds in a day	100,000	86,400 rounded up. Makes every QPS figure about 15% low, which you say aloud.
Daily volume to QPS	Divide by 100,000. 1M/day = 10 QPS. 1B/day = 10k QPS.	The single most useful conversion in the round.
Peak multiplier	3× average, or 10× for spiky products	Ticket sales and live events are 10×. A messaging app is nearer 2×.
Powers of two	2¹⁰ = KB, 2²⁰ = MB, 2³⁰ = GB, 2⁴⁰ = TB, 2⁵⁰ = PB	Turns a bit count into a size without hesitation.
Metadata row	100 bytes (a few int64 ids and a timestamp)	int64 = 8 B, UUID = 16 B binary, timestamp = 8 B.
Short text post	300 bytes with metadata	280 characters plus author id, post id, created_at.
Chat message	250 bytes	About 100 B of text and 150 B of ids, timestamp and delivery status.
URL row	200 bytes	About 100 B of long URL, a 7 B code, owner, created_at, index overhead.
Photo	Thumbnail 10 KB, web size 300 KB, original 2 MB	All three get stored, so budget the original plus about 10%.
Storage per year	1 KB/s = 30 GB/yr. 1 MB/s = 30 TB/yr. 1 GB/s = 30 PB/yr.	86,400 × 365 is about 31.5 million, so rate × 30 million.
Replication	Multiply raw storage by 3	Then say whether you would use erasure coding instead for cold objects.

The second half is what one machine can actually do. Quote these as ranges, because they move with hardware and workload, and a candidate who says "somewhere between five and ten thousand, and here is what would push it to either end" reads as more experienced than one who states a single confident wrong number.

One machine	Ballpark	Latency reference	Ballpark
Stateless API server	1k to 10k QPS	L1 cache reference	~1 ns
Relational DB, indexed reads	5k to 10k QPS	Main memory read	~100 ns
Relational DB, writes	1k to 5k/s	Read 4 KB from SSD	~100 µs
Redis or similar, in memory	~100k ops/s	Same-datacentre round trip	~0.5 ms
Kafka broker	~100k msg/s, hundreds of MB/s	Read 1 MB sequentially from SSD	~1 ms
Open sockets held	100k to 1M, memory bound	Spinning disk seek	~10 ms
NIC throughput	10 Gbps = 1.25 GB/s	Cross-continent round trip	~150 ms
RAM per box	64 to 256 GB	User-facing p99 target	100 to 200 ms

Two consequences are worth saying aloud when they come up. Memory is roughly a thousand times faster than an SSD, so a cache hit and a cache miss are different systems, not the same system slightly slower. And a cross-continent round trip at 150 ms already eats most of a 200 ms budget, so anything global has to be served near the user no matter how fast your code is.

Three designs, estimated longhand

Each of these is under two minutes spoken. Notice that each one produces a different kind of number, which is exactly why all three keep getting asked.

Photo-sharing feed: the bytes are the problem

Assume 500M daily users, each opening the feed 10 times, each page showing 10 photos. Reads: 5 billion feed loads a day, divided by 100,000, is 50k QPS average, 150k at peak. Uploads: one user in ten posts once a day, so 50M photos a day, which is 500 uploads a second. Storage: 50M times 2 MB is 100 TB a day, about 40 PB a year, and 120 PB once replicated three ways.

Now the number that decides the architecture. Egress is 50k feed loads a second, times 10 photos, times 300 KB, which comes to 150 GB/s, or 1.2 Tbps. At 10 Gbps a box, that is 120 servers doing nothing but pushing bytes, before any application logic exists. A CDN here is not an optimisation, it is the design. Meanwhile the metadata is 50M rows at 300 bytes, about 15 GB a day and 5 TB a year, which fits comfortably in one ordinary database. Say both numbers next to each other. Four orders of magnitude apart is the entire justification for splitting blobs from metadata, and it lands far better as a comparison than as two separate facts.

URL shortener: prove it is small, then move on

Assume 1M new links a day and a 100:1 read to write ratio, so 100M redirects. Writes are 10 a second. Reads are 100M over 100,000 seconds, so 1,000 QPS, 3,000 at peak. Storage: 1M times 200 bytes is 200 MB a day, 70 GB a year, so a decade of links is about 700 GB and fits on a single disk. Key space: base62 over 7 characters is 62⁷, roughly 3.5 trillion codes. Even 6 characters gives 57 billion, which at a million a day is over 150 years of supply.

Bandwidth is a redirect response of a few hundred bytes, so 1,000 QPS is well under a megabyte a second. The honest conclusion, and interviewers like hearing it stated, is that one well-provisioned machine could serve this workload, and 30 days of links at 6 GB fits entirely in RAM. So you say it: capacity is not the interesting constraint here, and I would rather spend the remaining time on p99 latency for a globally distributed redirect, on generating keys without coordination or collisions, and on abuse and expiry. That reframing is what the question was fishing for all along.

Chat app: connections, not bytes

Assume 500M daily users sending 40 messages each: 20 billion messages a day, which over 100,000 seconds is 200k messages a second, 600k at peak. With a mix of one-to-one threads and small groups, call average fanout 2, so 400k deliveries a second. Bytes are almost nothing: 200k times 250 B is 50 MB/s of ingest, four orders of magnitude below the photo app at a similar user count.

Two numbers actually shape this design. First, concurrency. If 20% of users are online at peak that is 100 million open connections, and at a defensible 250k sockets a box that is 400 connection servers, plus a registry mapping each user to the box holding their socket. Second, retention. Keeping every message at 250 bytes is 5 TB a day and about 2 PB a year before replication, whereas deleting after delivery leaves only the undelivered backlog, perhaps a few hundred GB. One product decision moves storage by three orders of magnitude, and naming that trade rather than silently assuming it is what scores.

Rounding hard without sounding sloppy

Aggressive rounding is a seniority signal when it is narrated and a red flag when it is silent. The difference sits almost entirely in the sentence wrapped around the number.

Sounds like guessing	Sounds deliberate
"Let us say about a hundred thousand seconds in a day."	"86,400 seconds, I will use 100,000. That makes every QPS number I say roughly 15% low, and I will flag it if we get near a threshold."
"Photos are, I do not know, a couple of megabytes?"	"I will budget 2 MB a photo including the thumbnail and web-size derivatives. If it is really 5 MB the storage triples, but the CDN decision does not change."
"That comes to roughly 47,300 queries per second."	"Call it 50k. I need to know whether this is ten boxes or a thousand, and a factor of two does not change that answer."
"Assume 500 million daily users."	"I will assume 500M daily users and 10 opens each. If it is 50 opens my read path goes to 250k QPS, and I would want the CDN either way, so that input is not load bearing."
Silence, and then a number appears.	"20 billion a day, divided by 100,000 seconds, is 200,000 a second." Every intermediate said aloud, with the units attached to it.

Three habits carry the whole thing. Declare the precision you need before you calculate, because "one box or a thousand" licenses everything that follows. Round the numerator and the denominator in opposite directions where you can, and say that you did, so the errors partly cancel. And sanity check the output against something you already know: 500 photo uploads a second for a 500M-user product feels about right, and if you had produced 500,000 you would want to find the missing factor of a thousand before the interviewer does. Say "let me sanity check that" out loud. Nobody has ever lost points for it.

One more rule saves whole minutes. If a number does not change a decision, compute it, say it is small, and stop. "Metadata is a few TB a year, which is nothing, so I will not dwell on it" is a better use of ten seconds than a careful derivation of a figure that alters nothing downstream.

Where a live copilot is the wrong tool for this bit

This part of the interview is close to the worst case for live assistance, and it is worth being straight about that. Estimation is you talking for ninety seconds while the interviewer is silent, so a tool that listens to interviewer audio has almost nothing to work with. Interview Copilot transcribes the interviewer on-device and drafts a speakable answer in about a second, which fits behavioural rounds and rapid-fire technical questions well. It does not fit an arithmetic monologue you are meant to be narrating at a whiteboard, and glancing away mid-calculation is more visible than a thinking pause. The rest of the limits, plainly:

Windows 10 and 11 only. No macOS, no Linux, no mobile, no browser extension.
Capture exclusion covers screen sharing and screen recording, and nothing else. The overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots while staying visible on your own monitor. It does nothing about a webcam, a lockdown browser, eye tracking, a second-device camera, or a person sitting in the room.
Numbers you did not derive collapse on the follow-up. "Why 3× for peak?" and "what happens if photos are 5 MB?" arrive immediately, and a recited figure has no answer to either.
The rules belong to the company. Some interviews permit documentation and AI assistance and some do not. Read the instructions, and ask when they are ambiguous.

The useful preparation here is not live at all. It is drilling the table above until the conversions are reflexive, then running each of the three designs against a two-minute timer until you stop reaching for a calculator.

How to drill it

Pick four prompts, say a photo feed, a shortener, a chat app and a rate limiter, and estimate each one aloud in two minutes with a timer in view. Then run the same four inside the 45-minute clock, because estimation that overruns steals time from the deep dive where the marks actually sit. The question banks give you prompts to work through, and the company Q&A generator builds a bank for a specific company and role, which matters because an infrastructure team and a consumer product team weight these numbers very differently. OfferPilot AI has a free tier of 5 minutes a day with no card, and paid plans start at $39 a month, metered on listening time only.

Back-of-the-envelope estimation: the numbers to have memorised