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

Back-of-the-envelope estimation is the five minutes in a system design interview where you turn vague scale ("it's like WhatsApp") into numbers that drive architecture. Done well, it makes every later decision feel inevitable: "we need about 700K writes per second at peak, so a single primary database is out; let's partition by conversation ID." Done badly, it is either skipped, so your design floats without justification, or it becomes a 15-minute arithmetic exam. This guide gives you the numbers, the formulas, and three complete worked examples you can adapt.

Why Interviewers Ask for Capacity Estimation

Nobody expects you to know Instagram's real traffic. The interviewer is checking three things:

1. Can you make reasonable assumptions and state them? Engineers constantly design without full data. Saying "I'll assume 100M DAU; tell me if you want a different scale" is a professional habit.
2. Do you know the physical limits of hardware? If your numbers say you need 50 TB of RAM for a cache and you propose "one Redis node", that is a red flag.
3. Do the numbers change your design? Estimation that leads nowhere is wasted time. The good candidate computes read/write ratio and immediately says "reads dominate 100:1, so caching and read replicas are the main lever".

At Indian product companies such as Flipkart, Swiggy, Razorpay or PhonePe, interviewers frequently anchor scale to Indian events: Big Billion Days, IPL final, Tatkal booking at 10 AM, UPI on the first of the month. Those are spike problems, so peak factor matters more than the daily average. See System Design Interview Preparation India 2026 for how the overall round is structured.

The Numbers Worth Memorizing

Powers of two and data units

The useful trick: count × size in bytes becomes trivial if you map millions to MB and billions to GB. One billion records of 1 KB each is 1 TB. One million images of 500 KB each is 500 GB.

Time conversions

Burn the last one in: 1 million per day ≈ 12 per second. So 100M/day ≈ 1,200/s, 1B/day ≈ 12,000/s, 10B/day ≈ 120,000/s. Most QPS questions reduce to this table.

Typical object sizes

These are estimates for interviews, not specs. Remember the units trap: network speeds are in bits per second, storage in bytes. Divide Mbps by 8 to get MB/s.

Latency Numbers Every Engineer Should Know

The famous list popularized by Jeff Dean and Peter Norvig is dated in the details (memory bandwidth and SSDs have improved a lot), but the ratios still drive design. Approximate values:

What the ladder tells you

• Memory is ~1,000× faster than SSD random reads, which is why a cache in front of a database helps so much.
• A network hop in the same data center costs ~0.5 ms. A request that fans out sequentially to 20 microservices pays ~10 ms just in hops. Parallelize fan-out or reduce hops.
• Cross-region round trips are 50 to 250 ms. Synchronous replication across continents adds that to every write; it is why globally consistent writes are expensive and why Indian users of a US-only deployment feel lag.
• Sequential I/O beats random I/O, which is the design principle behind append-only logs (Kafka) and LSM trees (Cassandra, RocksDB).

The Four Core Formulas

1. Traffic (QPS). average QPS = DAU × actions per user per day ÷ 86,400; peak QPS = average × peak factor (2 to 3 typical, 10+ for events). Compute reads and writes separately.
2. Storage. storage = new objects per day × object size × retention days × replication factor. Add indexes and metadata overhead (often 20 to 50 percent) if it matters.
3. Bandwidth. ingress = write QPS × request size, egress = read QPS × response size. Convert to bits for network: × 8.
4. Cache memory. cache = daily unique read objects × size × hot fraction. The 80/20 heuristic (20 percent of items get 80 percent of reads) gives "cache 20 percent of a day's read set" as a starting point.

And one derived formula: servers = peak QPS ÷ per-server capacity, with headroom (run at 50 to 70 percent utilization so a node or zone can fail).

SECONDS_PER_DAY = 86_400

def estimate(dau, writes_per_user, reads_per_user, obj_bytes,
             retention_days, replication=3, peak_factor=3, hot_fraction=0.2):
    writes_day = dau * writes_per_user
    reads_day = dau * reads_per_user
    w_qps = writes_day / SECONDS_PER_DAY
    r_qps = reads_day / SECONDS_PER_DAY
    storage = writes_day * obj_bytes * retention_days * replication
    return {
        "write_qps_avg": round(w_qps),
        "write_qps_peak": round(w_qps * peak_factor),
        "read_qps_avg": round(r_qps),
        "read_qps_peak": round(r_qps * peak_factor),
        "storage_TB": round(storage / 1e12, 1),
        "ingress_MBps": round(w_qps * obj_bytes / 1e6, 1),
        "egress_MBps": round(r_qps * obj_bytes / 1e6, 1),
        "cache_GB": round(reads_day * obj_bytes * hot_fraction / 1e9, 1),
    }

# A Twitter-like timeline: 200M DAU, 2 posts and 100 post reads per user per day
print(estimate(200e6, 2, 100, 1_000, retention_days=365 * 5))

Running it gives ~4.6K write QPS average, ~231K read QPS average (~694K peak), about 2.2 PB of tweets over five years with 3× replication, and a cache budget of ~4 TB if you naively cache 20 percent of every read. That last number is an overestimate, because reads hit the same popular tweets repeatedly; the cache should be sized on unique hot objects. Catching that kind of subtlety out loud is exactly what earns points.

Warm-Up: A URL Shortener in 90 Seconds

This is the simplest complete estimate and a template for the others.

Design consequences: 1,200 writes/s is comfortable for a single well-tuned database primary, but 90 TB is not comfortable on one node, so you shard by short key. Reads are cacheable and fit in memory. Seven characters is enough. Three numbers, three decisions. The same reasoning appears in Design Pastebin.

Worked Example: Estimating WhatsApp-Scale Chat

Assumptions are mine for the exercise, chosen to be round and plausible; WhatsApp's real internal numbers are not public in this detail. Say these out loud and invite the interviewer to change them.

Assumptions

• 500M daily active users.
• Each sends 40 messages per day.
• Text message: ~100 bytes payload + ~100 bytes metadata (IDs, timestamps, status) ≈ 200 bytes.
• 10 percent of messages carry media, averaging 100 KB after compression.
• At peak, 25 percent of DAU are connected simultaneously.
• Messages are stored on the server until delivered and then deleted (WhatsApp's documented model), but we will also compute permanent storage for comparison.

Message throughput

500M × 40 = 2 × 10¹⁰ messages/day. Divide by 86,400: ~231K messages/s average. With a 3× peak factor (evenings, New Year's midnight is far higher): ~700K messages/s. Each message implies at least a write, a delivery push and a delivery receipt, and group messages fan out to every member, so internal operations are several times higher.

Storage

• Text: 2 × 10¹⁰ × 200 B = 4 × 10¹² B = 4 TB/day.
• If kept forever (Telegram-style cloud history): 4 TB × 365 ≈ 1.5 PB/year, ×3 replication ≈ 4.4 PB/year.
• Store-until-delivered: most messages deliver within seconds; if 5 percent wait for offline users for up to 30 days, the pending store is roughly 4 TB × 0.05 × 30 ≈ 6 TB. Tiny.
• Media: 2 × 10⁹ media messages × 100 KB = 2 × 10¹⁴ B = 200 TB/day. Media dominates text by 50×, so it goes to object storage plus CDN, not to the message database.

Bandwidth

• Text ingress: 231K/s × 200 B ≈ 46 MB/s ≈ 370 Mbps. Trivial.
• Media ingress: 200 TB/day ÷ 86,400 ≈ 2.3 GB/s ≈ 18.5 Gbps average, before fan-out to recipients multiplies egress.

Connections, the number that actually shapes the design

• Concurrent connections at peak: 500M × 0.25 = 125M persistent connections.
• If one gateway server holds 100K connections comfortably (TLS state, buffers, heartbeats), you need ~1,250 servers; at 500K per server, ~250. WhatsApp's engineering blog reported over 2 million connections on a single Erlang server back in 2012, so the upper bound per box can be high with careful tuning.
• Heartbeats: 125M connections pinging every 30 s = ~4.2M heartbeats/s, more than the message rate. That is a non-obvious insight worth stating; it argues for lightweight heartbeat handling in the gateway itself, never touching a database.
• Connection memory: at ~20 KB per connection, 100K connections need ~2 GB of RAM per server. Fine.

Worked Example: Estimating YouTube-Scale Video

Two commonly cited public figures make good anchors: YouTube has said that over 500 hours of video are uploaded every minute, and in 2017 it announced viewers watch over a billion hours a day. Treat them as interview assumptions; current figures are likely higher.

Upload and storage

• 500 hours/min × 60 × 24 = 720,000 hours uploaded per day.
• Assume uploads average ~1 GB per hour of video (about 2.2 Mbps; many are higher, many shorter clips are lower). Originals: ~720 TB/day.
• Transcoding into a ladder of resolutions (144p to 1080p, maybe 4K, in two codecs) adds, say, 1.5 GB per hour of source: ~1.1 PB/day.
• Total ~1.8 PB/day. With 3× replication ~5.4 PB/day, about 2 exabytes per year. With erasure coding at ~1.5× overhead instead of 3× replication, roughly half that. This is why cold videos move to cheaper storage tiers.
• Upload ingress: 720 TB/day ÷ 86,400 ≈ 8.3 GB/s ≈ 67 Gbps.

Viewing bandwidth

• 1 billion watch-hours/day ÷ 24 = ~42M concurrent streams on average.
• Assume an average delivered bitrate of 3 Mbps (lots of mobile at 480p/720p, some 4K TVs).
• Egress: 42M × 3 Mbps ≈ 125 Tbps average, maybe 250 Tbps at peak.
• A well-provisioned edge server might push 50 to 100+ Gbps. Even at 100 Gbps each you need thousands of edge servers at peak, spread across ISPs, which is exactly why YouTube and Netflix place caches inside ISP networks.

Metadata traffic

• If an average view lasts 10 minutes, 1B hours = 6B views/day ≈ 70K views/s.
• Each view triggers metadata reads (title, channel, counts, recommendations, comments), so metadata read QPS is several hundred thousand per second, heavily cacheable.
• View counts at 70K increments/s should not be individual database writes; batch them through a stream processor.

The full design built on these numbers is in Design YouTube / Netflix.

How Many Servers? Per-Node Rules of Thumb

The hardest number to estimate is per-server capacity, because it depends on the work each request does. These are rough orders of magnitude for planning conversations, not benchmarks; measure before buying hardware.

Worked: a feed service needs 60K read QPS at peak, each instance handles ~2,000 at 60 percent CPU, so 30 instances plus N+2 redundancy across three availability zones means you deploy about 36. You do not need more precision than that in an interview.

Mental Math Shortcuts That Save Time

• Work in powers of ten. 500M × 40 = 5 × 10⁸ × 4 × 10¹ = 20 × 10⁹ = 2 × 10¹⁰. Multiply mantissas, add exponents.
• Divide by 10⁵ for per-second. 2 × 10¹⁰ per day ÷ 10⁵ = 2 × 10⁵ per second. You can mention that the true value is about 16 percent higher.
• Round to one significant figure at every step. 86,400 → 100K, 365 → 400 (or 300 if you want to stay conservative), 1,024 → 1,000.
• Use the 12-per-second anchor for anything stated "per day".
• Bits vs bytes: multiply bytes/s by 8 (or by 10 for a quick overhead-inclusive figure) to get bits/s.
• Peak factors: 2–3× normal diurnal peak; 10× for scheduled events; 100× if a single moment matters (Tatkal opening, flash sale start, a wicket in an IPL final driving app opens).
• Read/write ratios: social feeds and content are 100:1 or more; chat is close to 1:1; logging and metrics are write-heavy.

How to Present Estimates in an Interview

1. Ask or propose scale. "Should I assume India-only scale, around 50M DAU, or global?" If they shrug, pick round numbers.
2. Estimate only what matters for this problem. For chat: message rate, connections, media storage. For a URL shortener: key space and read QPS. For a rate limiter: memory per tracked key. Skip the rest.
3. Write a compact table on the board: DAU, read QPS, write QPS, peak, storage per year, bandwidth. It becomes a reference you point back to.
4. Sanity check. "~5 PB a year of video seems plausible for a top-tier video platform; 5 TB would be far too small."
5. Draw the conclusion. Every row should end in a design implication: shard, cache, CDN, async queue, or "a single node is fine".

Time box it to 3 to 5 minutes for a 45 to 60 minute round. If the interviewer says "skip the math", do not argue; you can still estimate one number later when it decides something, for example cache size when you introduce Redis. For how this fits into the full answer structure and the deep dives that follow, see System Design for Beginners and the caching sizing discussion in Design a Distributed Cache.

Follow-up questions interviewers ask after your numbers

• "What happens at 10× this load?" (Which component breaks first? Usually the database primary or a hot partition.)
• "How much would this cost?" (Rough cloud pricing: storage per GB-month, egress per GB. Egress at YouTube scale is the dominant cost, hence ISP peering.)
• "Your average hides a hot key. What is the peak for one celebrity / one popular product?" (Per-key QPS, not just total QPS, decides whether a single shard melts. See Database Sharding Explained.)
• "How many partitions or shards?" (Total size ÷ comfortable size per shard, and peak write QPS ÷ comfortable writes per shard; take the larger.)

Common Estimation Mistakes

Practice by taking any app on your phone (Swiggy, Hotstar, Zerodha Kite, Instagram) and estimating its peak QPS, storage per year and egress in under five minutes. After ten repetitions the numbers become automatic, and you will spend your interview time on the design itself, which is where it belongs.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.