Back-of-Envelope Estimates

Option C — a narrated, step-by-step estimation chain with explicit assumptions and a peak multiplier.

Back-of-envelope estimation structure:

1. Base number: "let's say [X]M monthly active users"
2. Daily active rate: "approximately 20% are active daily → [Y]M DAU"
3. Per-user behavior: "each user makes ~10 requests/day"
4. Total per day: "[Y]M × 10 = [Z]M requests/day"
5. Per second: "divide by 86,400 seconds → [N] rps"
6. Peak adjustment: "peak traffic is ~3–5× average → [P] rps at peak"

Key vocabulary:
• "Let's say / let's assume" — opens an assumption explicitly
• "roughly / approximately / around" — signals estimated values
• "on average" — distinguishes average from peak
• "at peak / peak traffic" — addresses worst-case load
• "Divide by 86,400 seconds" — showing the calculation builds confidence

86,400 seconds in a day = memorise this for system design. Useful multiples:
• 1 day = 86,400 s ≈ 10⁵ s
• 1 month = ~2.6M s ≈ 3×10⁶ s
• 1 year = ~31.5M s ≈ 3×10⁷ s

Why estimation fluency matters:
In system design discussions, the calculation itself is less important than narrating your reasoning clearly — interviewers and colleagues want to see that you can reason under uncertainty.

Option B — explicit per-unit arithmetic, correct unit labels, and order-of-magnitude extrapolation.

Per-unit storage estimation structure:

[Number of users] × [uploads per user per day] × [size per item]
= [total storage per day]

[Daily] × [days per year] × [years] × [growth factor]
= [total storage over system lifetime]

Common storage unit conversions to know:
• 1 KB = 10³ bytes
• 1 MB = 10⁶ bytes
• 1 GB = 10⁹ bytes
• 1 TB = 10¹² bytes
• 1 PB = 10¹⁵ bytes
• 1 EB = 10¹⁸ bytes

Narration patterns:
• "that's [X] × [Y] = [Z]" — narrate the multiplication
• "which gives us roughly" — introduces a rounded result
• "we're talking about [order-of-magnitude]" — e.g., "exabyte-scale"
• "over 5 years at 10× growth" — extrapolation frame
• "that's on the order of" — signals approximate

Replication factor:
In practice, multiply raw storage by the replication factor (typically 3× for distributed storage like HDFS, S3). Always mention this: "Raw storage × 3 for replication = actual storage required."

Option C — gives the order-of-magnitude result, names the scale, and draws a practical infrastructure conclusion.

Order-of-magnitude vocabulary:
• "We're in the ballpark of" — conversational OM phrase
• "on the order of" — more formal
• "roughly" — signals approximation
• "in the [X]-scale" — e.g., "terabyte-scale", "petabyte-scale", "gigabyte-scale"
• "an order of magnitude [larger/smaller] than" — comparing two estimates; ×10 difference

Order of magnitude examples:
• "1 billion (10⁹) is an order of magnitude larger than 100 million (10⁸)"
• "We're in the terabyte range, not the gigabyte range"
• "This is exabyte-scale — beyond what a single cluster can hold"

Drawing a conclusion from the estimate (important!):
The best back-of-envelope answers don't just compute a number — they map it to a practical consequence:
• "petabyte-scale → distributed object storage (S3, GCS)"
• "7,000 rps → need horizontal scaling; single server will not handle this"
• "10TB/day → streaming ingest pipeline (Kafka), not synchronous writes"
• "200ms per request at P99 → need a CDN or edge caching layer"

This is the skill that distinguishes system design experts: the estimate leads to a concrete architectural decision.

Option C — uses a known rounding (86,400 → 10⁵), states the rounding direction, and notes its effect on the estimate.

Rounding language in estimation:
• "rounding up to be conservative" — standard phrase; conservative = worst-case; used when you want to provision more, not less
• "rounding down to be optimistic" — rare in infrastructure; used when making a business case for cost
• "that's a safe upper bound" — after rounding up
• "to keep the arithmetic clean, I'll use [rounded value]" — explains the rounding choice
• "that's close enough for a back-of-envelope" — explicitly disclaiming precision

Standard rounding values to know:
• 86,400 → 10⁵ (100K)
• 30 days/month → use 30 or 31
• 365 days → use 400 for quick arithmetic; use 365 for accuracy
• 1M monthly active users → "let's call it 1M" is fine
• Latency: 1ms (in-memory), 100μs (L3 cache), 10μs (L2), 100ns (L1), 1ns (registers)

Conservative vs. optimistic matters:
When provisioning infrastructure, always round up — you'd rather over-provision than have an outage. When estimating costs for a budget, being clear about which direction you're rounding is critical to avoid surprises.

Option C — complete, narrated bandwidth calculation with concurrent users, per-user rate, aggregation, peak multiplier, and an architectural conclusion.

Bandwidth estimation structure:

[Concurrent users] × [per-user bandwidth] = [total bandwidth]
× [peak multiplier] = [peak bandwidth]
→ [architectural consequence]

Bandwidth vocabulary:
• "concurrent users" — users active simultaneously (not total users)
• "egress bandwidth" — data flowing OUT of your infrastructure (what you pay for)
• "ingress bandwidth" — data flowing INTO your infrastructure
• "at peak" — maximum load condition
• "CDN" (Content Delivery Network) — distributes bandwidth load globally
• "throughput" — data transferred per unit of time

Unit conversions:
• 1 Gbps = 1,000 Mbps = 10⁹ bits/s
• 1 Gbps ≈ 125 MB/s (divide by 8 for bytes)
• 1 MB ≈ 8 Mbits

Estimate steps when given bandwidth questions:
1. Start with concurrent users (not total users)
2. Establish per-user rate: streaming (1–8 Mbps), web page load (~2 Mbps burst), API calls (~1 Kbps)
3. Multiply: concurrent × per-user = total
4. Apply peak multiplier (2–5×)
5. Compare to single-server limits (~10 Gbps typical datacenter NIC)
6. Draw the architectural conclusion

Option B — explicit compounding growth calculation narrated year-by-year with a planning conclusion.

Growth extrapolation structure:

Start: [current metric] growing at [rate] year-over-year.
Year 1: [×2 from start]
Year 2: [×4 from start]
Year 3: [×8 from start]
→ "plan for [X×] today's baseline"

Growth rate phrases:
• "growing at 100% year-over-year" — doubling annually
• "~50% YoY growth" — 1.5× per year
• "10× growth over 3 years" — total multiplier
• "at this rate, we're looking at…" — extrapolation opener
• "assuming linear / exponential growth" — model choice

Common growth multipliers:
• 100% YoY = 2× per year = 8× in 3 years = ~32× in 5 years
• 50% YoY = 1.5× per year = ~3.4× in 3 years = ~7.6× in 5 years
• 20% YoY = 1.2× per year = ~1.7× in 3 years

Planning conclusion language:
• "I'd design for 10× current capacity"
• "We need an architecture that can scale horizontally without a rewrite"
• "At 8× we'd be hitting our current database limits — plan for sharding at ~4× to give lead time"
• "Build for 5× now, re-evaluate at 3× with a clear migration path"

In real design conversations, the specific numbers matter less than demonstrating you can reason about growth systematically and draw concrete planning conclusions.