InterviewSam
Log inStart free
System Design
Intermediate 12 min read How to answer

Back-of-the-envelope estimation

In one line

Rough numbers for QPS, storage, bandwidth and memory, worked out in two minutes, tell you which parts of the system are hard and which are easy.

What it is

Back-of-the-envelope estimation is quick arithmetic with rounded numbers to find the order of magnitude of load: requests per second, storage per year, network bandwidth, cache memory and number of servers. Being within 2x to 5x is fine; being off by 1000x is not.

Estimates are only useful when they lead to a decision. '58,000 reads per second' means little; '58,000 reads per second is too much for one Postgres primary but easy for a Redis cluster, so we cache the feed' is the point.

You need a small set of reference numbers in your head: seconds in a day, powers of ten for data sizes, rough latencies of memory, SSD and network, and rough capacity of common components.

Why interviewers ask

Interviewers use estimation to see whether your design is grounded in reality. Candidates who skip it often over-engineer (sharding a 50 GB database) or under-engineer (one server for 100,000 writes per second). Fast, clear estimates that change your design are a strong senior signal.

How it works

  1. 1Start from users and actions: DAU x actions per user per day = actions per day. Do reads and writes separately.
  2. 2Convert to per second: divide by about 100,000 (a day is 86,400 seconds). 1M per day is about 12 per second; 100M per day is about 1,200 per second.
  3. 3Apply a peak factor: 2x to 5x for normal daily peaks, much more for flash events (a sale launch, a Tatkal window, a cricket final) where traffic can be 10x to 50x within a minute.
  4. 4Storage: items per day x size per item x retention. Add replication (often 3x) and indexes. Separate small metadata (database) from large blobs (object storage).
  5. 5Bandwidth: QPS x response size. 10,000 requests per second x 100 KB = 1 GB/s egress, which says CDN.
  6. 6Cache memory: use the 80/20 rule. Caching the hottest 20% of a day's read data is often enough. Check it fits in a few nodes with tens of GB RAM each.
  7. 7Servers: divide peak QPS by a rough per-node capacity. A typical stateless API node handles hundreds to a few thousand requests per second depending on work per request.
  8. 8Say the conclusion out loud: which component is the bottleneck and what that means for the design.

Worked example · Estimating a WhatsApp-like chat service for India

  1. Assume 300M DAU, each sends 40 messages a day: 12 billion messages a day.
  2. Writes per second: 12B / 100,000 = 120,000 messages per second on average; peak about 3x = 360,000 per second (New Year's midnight can be higher).
  3. Message size: about 100 bytes of text plus about 200 bytes of metadata = about 300 bytes. Per day: 12B x 300 B = 3.6 TB. Per year: about 1.3 PB before replication.
  4. Conclusion 1: no single database can take 360,000 writes per second, so we need a horizontally partitioned store such as Cassandra or ScyllaDB, partitioned by chat ID.
  5. Connections: if 100M users are online at peak and each connection server holds about 500,000 idle connections, we need about 200 servers just for connections.
  6. Media: if 5% of messages are images of 200 KB, that is 600M x 200 KB = 120 TB a day, so media goes to object storage and a CDN, and only the URL goes in the message.
  7. Conclusion 2: the hard parts are write throughput, connection count and media storage, not the read API. The deep dives follow from that.

Picture it

It is like a caterer planning a wedding. They do not count every grain of rice; they multiply guests by plates by grams and add a buffer. The rough number decides whether you need one cook or a whole kitchen team.

Reference code

DAY = 100_000  # seconds, rounded from 86,400

dau = 300e6
msgs_per_user = 40
msg_bytes = 300
peak_factor = 3

per_day = dau * msgs_per_user              # 1.2e10
avg_qps = per_day / DAY                    # 120,000
peak_qps = avg_qps * peak_factor           # 360,000
storage_per_year_tb = per_day * msg_bytes * 365 / 1e12  # ~1,314 TB

print(f"avg {avg_qps:,.0f}/s, peak {peak_qps:,.0f}/s, {storage_per_year_tb:,.0f} TB/yr")

Key patterns

Round to powers of ten

When: Every calculation

How: Use 100,000 seconds per day, 1 KB = 1,000 bytes, 30M becomes 3 x 10^7. Multiply mantissas and add exponents. Clean numbers keep you fast and reduce arithmetic errors on a whiteboard.

Separate metadata from blobs

When: Estimating storage

How: Small structured fields go in a database; images, video and files go to object storage. Estimate them separately because they lead to different technologies and costs.

Estimate the scarce resource

When: Deciding what to compute

How: Only estimate what can break the design: write QPS for a chat app, concurrent connections for live tracking, egress for video, memory for a cache. Skip numbers that are clearly small.

Real-world use

Latency numbers every programmer should know

A list popularised by Jeff Dean at Google: main memory reference about 100 ns, SSD random read about 100 microseconds, round trip within a data center about 0.5 ms, a cross-continent round trip about 150 ms. The exact values have changed over the years; the orders of magnitude are what you use.

JioHotstar and cricket streaming

Hotstar reported about 25 million concurrent viewers during the 2019 Cricket World Cup, and newer IPL and India matches have gone higher. Capacity planning for such events is estimation first: concurrent users x bitrate gives the CDN bandwidth to reserve.

UPI volume

UPI crossed 20 billion transactions in a month in 2025. That is roughly 650M a day, about 7,500 per second on average, with much higher peaks at month start and in the evening, split across banks, payment apps and NPCI's switch.

In a project

Your team wants to store every product view event on an e-commerce app in Postgres for a 'recently viewed' feature and analytics.

  1. Estimate: 40M DAU x 30 product views = 1.2B events a day, about 12,000 per second average, 60,000 per second at a sale peak.
  2. Size: 100 bytes per event = 120 GB a day, about 44 TB a year.
  3. Conclusion: a single Postgres primary will struggle with 60,000 inserts per second, and 44 TB a year is expensive to keep in an OLTP database.
  4. Split the need: 'recently viewed' needs only the last 50 items per user, which fits in Redis (40M users x 50 x 16 bytes for IDs is about 32 GB).
  5. Send all events to Kafka and land them in an OLAP store or object storage for analytics.
  6. Present the numbers in the design review so the decision is easy to accept.

Impact: The team avoids a database that would have fallen over during the first sale, the feature is served from memory in under 5 ms, and analytics gets cheap columnar storage.

Trade-offs

Use it when

  • Right after requirements, to find the bottleneck
  • When choosing between a single database and a partitioned one
  • When deciding whether a cache fits in memory
  • When an interviewer challenges a choice: numbers settle arguments

Avoid it when

  • Spending more than about 5 minutes; precision is not the goal
  • Computing numbers you will not use in any decision
  • Using exact 86,400 and long division on the board when 100,000 is good enough

Common mistakes

  • Computing numbers and never using them to justify a design choice.
  • Forgetting the peak factor and designing only for the average.
  • Mixing up bits and bytes, or MB and GB, and ending 1000x off.
  • Putting images or video size into the database storage estimate.
  • Forgetting replication factor and indexes in storage estimates.
  • Assuming one server handles a million requests per second, or that one Postgres can never pass 1,000 writes per second; both extremes are wrong.

Interview questions

Quick revision

  • 1 day is about 100,000 seconds; 1M per day is about 12 per second.
  • Peak: 2x to 5x normally; 10x to 50x for flash events.
  • Sizes: KB 10^3, MB 10^6, GB 10^9, TB 10^12, PB 10^15 bytes.
  • Memory about 100 ns, SSD read about 100 us, same-DC round trip about 0.5 ms, cross-continent about 150 ms.
  • Redis node: around 100,000 simple ops per second; stateless API node: hundreds to a few thousand RPS.
  • Single SQL primary: thousands of simple writes per second; beyond that, partition or queue.
  • Storage = items x size x retention x replication (often 3).
  • Bandwidth = QPS x response size; large media means CDN.
  • Always finish with 'so this means...'.

Check yourself

1. A service gets 50M requests a day. Roughly what is the average QPS?

2. 10,000 requests per second each return 200 KB. What is the egress?

3. Why do we separate photo storage from metadata storage in estimates?

4. Which estimate matters most for a live location tracking service with 1M active couriers?

See it in a full design

These walkthroughs use this lesson.

Design a news feed (Facebook) Design a URL shortener (TinyURL / bit.ly) Design search autocomplete (typeahead) Design Pastebin Design a unique ID generator (like Snowflake) Design a web crawler Design object storage (like S3) Design ad click aggregation

Saved on this device. Create a free account to keep it on every device.

Clarifying requirements and scopeDesigning the API

Practise this with Sam

A real mock interview, out loud, with an honest scorecard. Free to start.

Start free