Back-of-Envelope Estimation

In plain words

Before you can design a system you need to know roughly how big it is: how many requests a second, how much data, how many bytes on the wire. Back-of-envelope estimation is getting those numbers from a few facts and some arithmetic — in a minute, to within a factor of two. Nobody is checking the second digit. What matters is spotting which number is big, because the big one decides the design.

The four conversions

1. Users → actions per day

   Daily active users × actions each. Be concrete about the action: a page view, a message, an upload. Different actions have different costs, so estimate the two or three that matter separately.

2. Per day → per second

   Divide by 86,400. Round it to 100,000 and the answer is within 15%: 1 million a day ≈ 12 a second. Then multiply by a peak factor — 2–3× for a global product, 5–10× for something with a rush hour.

3. Split reads from writes

   The ratio is usually lopsided — 10:1, 100:1 — and the two paths get different designs. Writes size the database; reads size the cache and CDN.

4. Rate × size → storage and bandwidth

   Writes per second × bytes per item × seconds per year is storage. Reads per second × bytes is bandwidth. Convert to bits (×8) for network numbers.

users            10 M/day
views            10 M × 10 sessions × 20 photos  =  2 B/day
                 2 B ÷ 86,400                     ≈  23 K/s     (peak ×3 ≈ 70 K/s)
uploads          10 M × 1                         =  10 M/day  ≈  115/s
storage          10 M × 2 MB                      =  20 TB/day  ≈  7 PB/year
egress           23 K/s × 200 KB (a resized copy) ≈  4.6 GB/s   ≈  37 Gbps  (peak ~110 Gbps)
metadata         10 M × 500 B                     =  5 GB/day   — trivially small

Everything about this design follows: photos go to object storage and a CDN, never through the API; the metadata database is small and boring; the upload path needs to write 20 TB a day without the API proxying it.

Numbers to carry in your head

seconds in a day (≈ 10⁵)

86,400

seconds in a month

2.6 M

seconds in a year

31.5 M

bytes to bits

×8

And the powers of two, because storage is quoted in them: 2¹⁰ ≈ 1 K, 2²⁰ ≈ 1 M, 2³⁰ ≈ 1 G, 2⁴⁰ ≈ 1 T. Kilo, mega, giga, tera, peta — each a thousand times the last.

What the numbers tell you

Where it goes wrong

• Averages without peaks. 23 K/s average is 70 K/s at 8 p.m. Size for the peak and say what multiplier you used.
• Forgetting the size of the thing. 23 K requests a second is nothing; 23 K × 200 KB is 37 Gbps, which is not.
• Counting requests, not work. One feed request is one list read plus 50 post fetches plus 50 image URLs. Count what the backend does, not what the client sends.
• Precision theatre. "23,148 requests per second" pretends to a certainty you do not have. Say "about 25 K" and move on.

Take this with you

• The one idea: a few multiplications turn "10 million users" into the one number that decides the design. Being within 2× is enough.
• In an interview, narrate the conversions, state your assumptions, and end with which number is big and what that implies.
• At work, do this before any capacity meeting. The playground's workloads are exactly these numbers — put them in and see what breaks.