Back-of-the-Envelope Estimation

The problem

The interviewer says: "Assume 100 million daily active users." Is that 1,000 requests per second or 1,000,000? Does the data fit on one machine? Without a quick estimate, every later decision (cache or not, shard or not) is a guess.

Real-world analogy

Before a road trip you don't compute fuel to the millilitre. You think: 600 km, about 7 litres per 100 km, so roughly 42 litres, one tank. Rough numbers, one decision: no fuel stop needed. Estimation in interviews works the same way.

The idea

Numbers worth memorising:

The recipe:

1. Traffic: daily active users × actions per user per day ÷ 100,000 = average requests per second. Multiply by 2–3 for the peak. Split reads and writes; most systems read far more than they write.
2. Storage: new records per day × record size × 365 × years to keep. Add replication (usually ×3).
3. Bandwidth: requests per second × response size.

Round aggressively: 86,400 becomes 100,000, 3.8 becomes 4. The goal is the order of magnitude, stated out loud.

The code

A reusable estimator. Change the inputs for any design question; this example is a photo-sharing app.

def human(n, unit=""):
    for suffix, size in [("T", 1e12), ("B", 1e9), ("M", 1e6), ("K", 1e3)]:
        if n >= size:
            return f"{n / size:.1f}{suffix}{unit}"
    return f"{n:.0f}{unit}"


def human_bytes(n):
    for suffix, size in [("PB", 1e15), ("TB", 1e12), ("GB", 1e9), ("MB", 1e6), ("KB", 1e3)]:
        if n >= size:
            return f"{n / size:.1f} {suffix}"
    return f"{n:.0f} B"


DAU = 50_000_000             # daily active users
UPLOADS_PER_USER = 0.2       # photos uploaded per user per day
VIEWS_PER_USER = 30          # photos viewed per user per day
PHOTO_SIZE = 500_000         # bytes, after compression
YEARS = 5
REPLICAS = 3
SECONDS_PER_DAY = 100_000    # rounded from 86,400

writes = DAU * UPLOADS_PER_USER / SECONDS_PER_DAY
reads = DAU * VIEWS_PER_USER / SECONDS_PER_DAY
storage = DAU * UPLOADS_PER_USER * PHOTO_SIZE * 365 * YEARS * REPLICAS
egress = reads * PHOTO_SIZE

print(f"uploads:   {human(writes)}/s average, {human(writes * 3)}/s peak")
print(f"views:     {human(reads)}/s average, {human(reads * 3)}/s peak")
print(f"read:write ratio  {reads / writes:.0f}:1")
print(f"storage:   {human_bytes(storage)} over {YEARS} years (x{REPLICAS} replicas)")
print(f"bandwidth: {human_bytes(egress)}/s served at average load")

uploads:   100/s average, 300/s peak
views:     15.0K/s average, 45.0K/s peak
read:write ratio  150:1
storage:   27.4 PB over 5 years (x3 replicas)
bandwidth: 7.5 GB/s served at average load

What these numbers decide: 150:1 reads to writes means caching and a CDN matter most; petabytes of photos means object storage, not a database; 15,000 views per second is too much for one database but easy for a CDN.

Common mistakes

• Precise arithmetic. Nobody needs 578.7 requests per second. Say "about 600" and move on.
• Estimating things that don't change the design. Skip numbers that won't affect a decision.
• Forgetting the peak. Systems must survive the busiest hour, not the average one.
• Mixing up bits and bytes, or MB and GB. Write units on every number.
• Not drawing a conclusion. Every estimate should end with "so we need…" (a cache, sharding, a CDN).

Key points

• 1 day ≈ 10⁵ seconds; 1 million per day ≈ 12 per second.
• Traffic = users × actions ÷ 10⁵, then ×2–3 for the peak; split reads and writes.
• Storage = records per day × size × days kept × replicas.
• Round hard, say the order of magnitude, then state the design consequence.