Back-of-the-envelope estimation for system design interviews

Numbers worth memorising

Time and scale

Rough latencies

Exact figures vary by hardware generation; what matters is the ratios between them.

Typical object sizes

• A short text record with metadata (tweet, chat message, URL mapping): 200 bytes to 1 KB.
• A compressed photo: 200 KB to 2 MB. A thumbnail: 10–50 KB.
• A minute of compressed 1080p video: tens of megabytes; streaming bitrates of a few Mbps.

A five-step method

1. Decide what you need to know. Usually peak QPS (reads and writes separately), total storage, and one problem-specific number such as fan-out or bandwidth.
2. State assumptions out loud. Daily active users, actions per user per day, object size, retention period, read/write ratio. Ask the interviewer if they have numbers in mind.
3. Compute with round numbers. Use powers of ten. Show the formula, not just the answer.
4. Apply a peak factor. Multiply the average by 2–3 (more for spiky products).
5. Draw a conclusion. "That's 350,000 reads per second, too much for a single database, so we'll cache and replicate." This is the step people forget, and it's the reason to estimate at all.

The core formulas

average QPS   = daily active users × actions per user per day ÷ 86,400
peak QPS      = average QPS × peak factor (2–3)
storage/day   = new objects per day × average object size
total storage = storage/day × 365 × years × replication factor
bandwidth     = QPS × average response size
cache size    = hot fraction × daily working set × object size

Worked example 1: a photo-sharing app

Assume 100M DAU, each viewing 50 photos and uploading 0.1 photos a day; photos average 1 MB, plus 3 resized versions totalling 300 KB.

• Uploads: 10M/day ÷ 10⁵ ≈ 100/s average, ~300/s peak. Small.
• Views: 5B/day ≈ 50,000/s average, ~150,000/s peak. Large: this is a CDN problem.
• Storage: 10M × 1.3 MB ≈ 13 TB/day ≈ 4.7 PB/year before replication. Object storage, not a database.
• Egress: if most views serve a 100 KB feed-size image, 150,000/s × 100 KB ≈ 15 GB/s at peak. Again: CDN.

Conclusion: metadata fits in a modest sharded database; the hard parts are blob storage and edge delivery.

Worked example 2: a chat service

Assume 500M DAU sending 40 messages a day at ~200 bytes each, with 20% of users connected at peak.

• Messages: 20B/day ≈ 230,000/s average, ~700,000/s peak.
• Storage: 20B × 200 B = 4 TB/day, roughly 1.5 PB/year before replication.
• Connections: 100M concurrent sockets; at ~100,000 per server that's around 1,000 connection servers.

Conclusion: a horizontally scaled stateful connection tier plus an append-optimised store partitioned by conversation. The full design is in design a chat app.

Worked example 3: is one machine enough?

Interviewers sometimes want to hear that you don't need a distributed system. A service with 1M DAU making 20 requests a day is ~230 requests/s average. With 1 KB per record and 10M records, the dataset is 10 GB. A single well-provisioned database with a replica (for availability) handles that comfortably. Saying so, then explaining at what scale you'd shard, scores better than reflexively drawing twenty boxes.

Common estimation mistakes

• Forgetting the peak factor, then sizing for average load.
• Mixing bits and bytes in bandwidth (network links are quoted in bits per second).
• Ignoring replication (typically 3×) and indexes when estimating storage.
• Spending ten minutes on arithmetic the design doesn't depend on.
• Producing numbers and never using them.

Estimation is step 2 of the system design interview framework; the URL shortener guide shows it applied end to end.