Back-of-the-Envelope Estimation

Beginner · 16 min read · High-Level Design, Foundations

Numbers every engineer should know and how to turn them into QPS, storage and bandwidth.

Back-of-the-envelope estimation is the skill of producing a rough-but-useful number quickly. In a design interview it answers questions like does this fit on one machine?, do we need a cache?, and is a CDN mandatory? — before you commit to an architecture.

The goal is order-of-magnitude correctness, not precision. Whether you need 40 or 60 servers doesn't change the design. Whether you need 1 or 1,000 does.

Why it matters

Estimation turns vague requirements into constraints that eliminate options:

Numbers worth memorising

Typical object sizes are equally useful:

The estimation method

Every estimate follows the same chain. Write it down step by step so the interviewer can follow — and correct an assumption if needed.

Worked example: a photo-sharing service

Assumptions (state them out loud):

Worked example: what does video egress cost?

Assumptions: 5M DAU, each watches 5 videos/day, average video delivered ≈ 300 MB, CDN price ≈ $0.02/GB.

Making the arithmetic easy

Interview questions

  • A service has 10M DAU and each user makes 20 requests per day. Do you need more than one server?
  • Why do we estimate peak QPS rather than average?
  • Your estimate shows 5 TB of data. Do you need to shard?
  • How much memory would you need to cache the hot set for 1 billion reads per day of 2 KB objects?
  • Practice: 400M monthly users, 50% active daily, 2 posts per user per day, 10% of posts carry a 1 MB image. Estimate write QPS and five-year media storage.

Practice

Write your answer before opening the suggested one. Anything you mark "Partly" or "Missed it" comes back in your review deck.

Further reading

Key takeaways

  • Aim for the right order of magnitude, not precision.
  • Memorise: 1 day ≈ 10^5 s; 1M requests/day ≈ 12 QPS; memory ≈ 1,000× faster than SSD.
  • Estimate reads and writes separately, and always size for peak.
  • Storage = writes × size × retention × replication.
  • End every calculation with "so…" and the design decision it drives.

Previous: The HLD Interview Framework · Next: Networking Essentials