Foundations

Back-of-the-Envelope Estimation

Back-of-the-envelope estimation is quick, rounded arithmetic that tells you which parts of a design are hard. It is not about precision: the question is whether a number is 10, 10,000 or 10 million, because each of those implies a different architecture. One database handles thousands of simple queries per second; it does not handle a million writes per second, and knowing that before you draw boxes saves the whole interview.

In simple words

Like estimating how many buses a school trip needs: 300 students, 50 seats per bus, so about 6 buses. You don't need the exact headcount to know that one bus won't do and twenty is too many. Estimation tells you which size of solution you need.

Users × actions ÷ seconds per day gives QPS; × item size gives storage; × payload gives bandwidth. Then decide.

Deep Dive: The Numbers Worth Memorising

Time
  1 day      = 86,400 s   ~ 10^5 s        (use 100K for mental math)
  1 month    ~ 2.5 x 10^6 s
  1 year     ~ 3 x 10^7 s

Powers of two / sizes
  2^10 ~ 1 thousand (KB)   2^20 ~ 1 million (MB)
  2^30 ~ 1 billion  (GB)   2^40 ~ 1 trillion (TB)   2^50 ~ PB

Typical sizes
  a UUID / id ........ 16 bytes (8 for a 64-bit id)
  a tweet-sized row .. ~ 300 bytes - 1 KB with metadata
  a compressed photo . ~ 200 KB - 2 MB
  1 min of HD video .. ~ 50-100 MB (before adaptive re-encoding)

Latency (orders of magnitude, commonly quoted)
  L1 cache ref ....................... ~1 ns
  main memory ref .................... ~100 ns
  SSD random read .................... ~100 us
  read 1 MB sequentially from memory . ~ 10s of us
  round trip within a datacenter ..... ~0.5 ms
  HDD seek ........................... ~10 ms
  round trip across continents ....... ~100-150 ms

Rough single-node capacities (very workload dependent)
  a web/app server ........ ~1K - 10K simple req/s
  a relational DB primary . ~ thousands of writes/s, more reads with cache/replicas
  Redis (one node) ........ ~ 100K ops/s
  Kafka partition ......... ~ 10s of MB/s

The latency ladder is the useful intuition: memory is about a thousand times faster than SSD, and a cross-continent round trip is about as slow as a thousand in-datacenter ones. That is why caches sit in memory, why chatty service-to-service calls hurt, and why global systems keep data near users.

Deep Dive: From Users to QPS, Storage and Bandwidth

Example: a photo-sharing app

Assume  100M DAU, each views 50 photos/day and uploads 1 photo per 10 days.

Read QPS    = 100M x 50 / 10^5 s          = 50,000 /s   (avg)
Peak        ~ 2-3x average                ~ 100K-150K /s
Write QPS   = 100M x 0.1 / 10^5           = 100 /s      -> read-heavy, 500:1

Storage     = 10M new photos/day x 1 MB   = 10 TB/day
per year    ~ 10 TB x 365                 ~ 3.6 PB/year (x3 if replicated 3 ways)
Metadata    = 10M x 1 KB                  = 10 GB/day   -> tiny next to the blobs

Egress      = 50K reads/s x 200 KB (thumbnail) = 10 GB/s  -> needs a CDN

Decisions these numbers force:
  - blobs go to object storage + CDN, not the database
  - metadata fits comfortably in a sharded (or even single + replicas) DB
  - the read path must be cached; the write path is small

The method is always the same: users × actions per user ÷ seconds per day = average QPS, then multiply for peak; items per day × size × retention × replication = storage; QPS × response size = bandwidth. Then say what each number means for the design.

Deep Dive: How Many Servers? (and Why It's Only a Sanity Check)

With peak QPS and a per-server throughput you can size a tier: 150K req/s ÷ ~5K req/s per server ≈ 30 servers, plus headroom for failures and deploys (say 40–50). For a cache: if the hot 20% of daily reads must fit in memory, 20% × 10 GB of metadata = 2 GB, which is one small Redis node; the photos themselves are the CDN's job. These numbers tell you "one", "tens" or "thousands", which is all the interview needs. Real capacity planning uses load tests, not rules of thumb.

Key Pointers

Round everything: 86,400 → 10⁵, 365 → 400 if it makes the math easier. State assumptions as you go.
Always separate reads from writes; the ratio decides caching vs partitioning.
Peak is typically 2–3× average (more for event-driven traffic such as sales or live sports).
Media (images, video) dominates storage and bandwidth; metadata is usually small. Put blobs in object storage behind a CDN.
Only estimate what changes a decision. Skip numbers that don't.

How It Works

Pin down DAU and the per-user rates of the main actions (reads, writes, uploads).
Convert to average QPS with ÷10⁵, then to peak with ×2–3.
Estimate item sizes, multiply by daily volume, retention and replication for storage.
Multiply QPS by payload size for bandwidth; decide whether a CDN is needed.
Translate into decisions: cache or not, shard or not, blob store, number of servers (order of magnitude).

Try It Yourself

A chat app has 50M DAU; each user sends 40 messages a day of ~100 bytes, and messages are kept for 5 years.

Messages/day = 50M x 40            = 2 x 10^9
Write QPS    = 2 x 10^9 / 10^5     = 20,000 /s   (peak ~ 50K /s)
Storage/day  = 2 x 10^9 x 100 B    = 200 GB/day
5 years      = 200 GB x 365 x 5    ~ 365 TB   (x3 replication ~ 1 PB)

So: write-heavy, append-only, partition by conversation id; a wide-column
store (Cassandra/HBase-style) fits better than a single relational primary.

Follow-up Questions

Why do we care about peak and not just average QPS?: Systems fall over at peak. Capacity, autoscaling limits and database connections must be sized for the busiest minutes, with headroom for a failed node.
Your storage estimate is 3 PB a year. What changes?: It can't live on one machine or in a relational database: blobs move to object storage, cold data moves to cheaper tiers with lifecycle rules, and you consider compression and deduplication.
Is it OK to be off by 2x?: Yes. Estimates exist to pick between architectures that differ by 10x or more. Being off by 2x rarely changes the design; being off by 1000x does, so double-check units (bits vs bytes, per day vs per second).

Trade-offs

Estimation trades accuracy for speed. The risk is false confidence in a precise-looking number built on guesses, so keep the assumptions visible and let the interviewer correct them. The payoff is that every later choice has a reason attached.