Back-of-the-envelope estimation
Wednesday, 16:30: Karim's investor slide says "StayHub is ready for 10× growth", and the meeting is Friday. Nobody can say whether 4 app servers and one PostgreSQL survive 300,000 guests a day.
Two minutes of rough math tells you if you need one server or a hundred. Here's how to do it without a calculator.
- Problem
Before building, you need to know whether a design needs 1 server or 100, 50 GB or 50 TB, a single database or shards.
- Why the simple system fails
Guessing by feel leads to either over-engineering (sharded clusters for 20 req/s) or outages (one database for 50k writes/s), and precise modelling takes too long to be useful early.
- Engineering concept
Estimate in orders of magnitude: users → requests/day → average QPS → peak QPS; objects × size × retention → storage; QPS × payload → bandwidth. Compare with known capacity and latency numbers.
- Technology
Powers of ten, the ~100k seconds/day shortcut, peak factors, read/write ratios, latency numbers (memory, SSD, network, cross-region), rough per-node capacities.
- Trade-offs
Speed and rough correctness versus precision. Estimates are for decisions, not invoices: right within a factor of ~2-3, then validated with load tests and metrics.
The problem
2 min- Karim · CTOSlide 9: "Ready for 10× growth." That's 300,000 guests a day. True? The meeting is Friday.
- You · Engineer at StayHubNo idea. We'd need weeks of load tests.
- Lina · Senior engineer, your mentorWeeks to be sure. Ten minutes to know whether it's 4 servers or 40. Guess first.
The big idea
4 minA estimate aims for the right power of ten, fast, at the peak, and every number must change a decision.
You don't need the exact guest list to book a wedding venue: 150 guests means a 200 m² room, not a stadium. Off by 20% changes nothing; off by 10× changes everything. And you staff for the toast, not the average hour.
How it works
5 min- 1Traffic
× actions each ÷ ~100,000 s = average (requests per second). Then × a : how much busier the busiest moment is, ~3× daily, 10×+ for a sale.
- 2Storage
New items per day × size × days kept × copies (indexes, replicas, backups).
- 3Bandwidth
Peak QPS × response size. Links are sold in bits: 1 Gbit/s ≈ 125 MB/s.
- 4Compare
Against rough capacities: one app server handles hundreds to a few thousand req/s; one PostgreSQL thousands of simple queries/s.
- 5Decide
Say what each number changes: more servers, a cache, a CDN, or nothing at all.
Watch a decision being made
4 minLina's one-page estimate for slide 9
Does StayHub (4 app servers, PostgreSQL + replica, Redis, CDN) survive 300,000 guests a day? What doesn't, and what does the fix cost?
- 1Write the assumptions, then traffic at the peak
~40 requests per guest (from logs), evening ×3, sale email ×10, ~400 req/s per server (Omar's load test), ~1 query per request after Redis.
text300,000 × 40 = 12,000,000 req/day 12M ÷ 100,000 s ≈ 120 req/s average × 10 (sale email) ≈ 1,200 req/s ← design for thisWhy: Written assumptions move the argument to "is 40 right?". Systems fall over at the known peak, not the average.
- 2Storage: count everything that grows
Bookings ≈ 9 GB/year (~27 GB with indexes). Audit log: 12M × 500 B = 6 GB a day, ~2.2 TB a year. Photos ~1.4 TB, already in object storage.
Why: The item nobody thinks of is usually the big one: the audit log is 80× the bookings.
- 3Bandwidth, in bytes and bits
Photos at the evening peak: ~60 MB/s ≈ 480 Mbit/s, roughly three times that on a sale evening.
Why: In bits, it's half a 1 Gbit/s server link: photos must keep coming from the CDN.
- 4Compare and decide
1,200 ÷ 400 = 3 busy servers of 4, only 3 left if one crashes → run 6 on campaign days. Database: ~1,200 queries/s, ~30 writes/s → no sharding. Audit log → object storage, 90-day retention.
Why: Three decisions, and one expensive non-decision (sharding) avoided.
In real life
3 minAmazon on Prime Day: absorb it
- Has publicly described adding a lot of capacity ahead of Prime Day
- Every shopper served normally, because nearly everything scales out
Fits a peak a few times normal that capacity can serve.
Big ticket sales: shape it
- Ticketmaster and others publicly use virtual waiting rooms for huge on-sales
- The site lets in only what it can serve
Fits demand that dwarfs both capacity and seats.
What goes wrong
3 minLogs, indexes and audit tables often outgrow business data.
List every table and file that grows.
463.7 req/s from guessed inputs suggests accuracy that doesn't exist.
Round hard, one significant figure, the right power of ten.
An 8× error decides whether a link is enough.
Convert explicitly: 1 Gbit/s ≈ 125 MB/s.
Trade-offs
3 min| Method | Fits when | You pay |
|---|---|---|
| Back-of-the-envelope | Early design, reviewing a proposal, "do we need X at all?" | Within 2–3×, not exact |
| Load test / capacity model | Before a launch or event, near a limit, cost commitments | Days or weeks; needs a working system |
- Omar · On-call SREEstimates are good to 2–3×. I wouldn't tell investors "ready" without a load test. Two weeks.
- Lina · Senior engineer, your mentorThen the slide says what we know: "10× needs 2 more servers on sale days and moving the audit log, about €600 a month". Load test before the summer sale.
- Omar · On-call SREAnd if our 400 req/s per server is really 150?
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- The assumptions (300,000 guests, ~40 requests each, ×3 evening, ×10 sale, ~400 req/s per server): Claude can measure some from logs; you decide which the plan rests on.
- Which peak you design for: the sale email (~1,200 req/s), not the 120 average.
- What each number changes, and which assumption you verify first ("~1 query per request after Redis").
Karim's slide says StayHub is ready for 10× growth (300,000 guests a day). No config changes. Write docs/design/10x-estimate.md. First measure from access logs: requests per guest, evening peak ratio, sale-email ratio, queries per request; show the commands. Then compute average and peak req/s, DB writes/s, yearly storage for bookings, audit log and photos, and peak photo bandwidth in MB/s and Mbit/s. List every assumption at the top, show formulas with units, and end with what each number changes.
- Every assumption has a source (log query, load test, or "assumed").
- Redo one line: 300,000 × 40 = 12M; ÷ 100,000 ≈ 120; × 10 ≈ 1,200.
- It counts everything that grows, including the audit log, and gives bandwidth in bytes and bits.
- It sizes for the average, not the peak.
- Precise-looking figures with no assumptions behind them.
- It forgets headroom for one failed server, or recommends sharding before showing the write rate.
Check yourself
2 minNext episode: Maya wants hotel links short enough to fit in an SMS, like stay.hb/x7Kp2, and you'll design the whole service yourself.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Interactive simulation, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Lina's one-page estimate for slide 9
Karim's slide claims StayHub is ready for 10× growth: 300,000 guests a day. Today StayHub runs 4 app servers, a PostgreSQL primary + replica, Redis and a CDN. Find out what survives, what doesn't, and what it costs to fix, on one page.
- 1Write the assumptions down
300,000 guests/day, ~40 API requests each (from today's logs), evening peak ×3, sale email ×10. One app server handles ~400 req/s on our workload (Omar's last load test). After Redis, ~1 database query per request.
Why: Assumptions are what people will challenge. Written down, the argument is about "is 40 right?" instead of "is your maths right?".
- 2Traffic: average, then peak
12M requests/day ÷ 10⁵ s ≈ 120 req/s. Evening ≈ 360. Sale email ≈ 1,200 req/s.
text300,000 × 40 = 12,000,000 req/day 12M ÷ 100,000 s ≈ 120 req/s average × 3 (evening) ≈ 360 req/s × 10 (sale email) ≈ 1,200 req/s ← design for thisWhy: Systems fall over at the peak, not the average. The sale email is a known, repeating event, so it's the number to plan for.
- 3Storage, counting everything that grows
Bookings: 25,000/day × 1 KB × 365 ≈ 9 GB/year, ~27 GB with indexes. Audit log: 12M × 500 B = 6 GB a day, ~2.2 TB a year. Photos: 18,000 hotels × 40 × 2 MB ≈ 1.4 TB, in object storage already.
Why: The item nobody thinks of is usually the big one. Here the audit log is 80× bigger than the bookings.
- 4Bandwidth, in bytes and bits
1.2M hotel page views/day × 8 photos × 200 KB ≈ 1.9 TB/day ≈ 19 MB/s average, ~60 MB/s at the evening peak (×3) ≈ 480 Mbit/s, and roughly three times that on a sale-email evening.
Why: Converting to bits shows it would eat half of a 1 Gbit/s server link. That's why photos must keep coming from the CDN.
- 5Compare with capacity, and decide
App servers: 1,200 ÷ 400 = 3 busy servers out of 4, and only 3 left if one crashes → run 6 on campaign days. Database: ~1,200 simple queries/s and ~30 writes/s → fine, no sharding. Audit log → move out of PostgreSQL to object storage with 90-day retention.
Why: This is the step that makes the estimate worth doing: three decisions, and one expensive non-decision (sharding) avoided.
| Operation | Approximate latency | Design implication |
|---|---|---|
| Main memory (RAM) read | ~100 ns | In-process caches are nearly free |
| SSD random read (4 KB) | ~20–150 µs | One index lookup is fast; thousands per request are not |
| Round trip inside a data centre | ~0.2–0.5 ms | 10 sequential service calls ≈ a few ms |
| Redis GET over the network | ~0.5–1 ms | Cache hits are ~10× faster than typical DB queries |
| Simple indexed DB query | ~1–5 ms | Fine once, painful 100× in a loop (N+1) |
| Round trip Europe ↔ US East | ~70–100 ms | Keep chatty traffic regional; use a CDN |
| Round trip Europe ↔ Asia-Pacific | ~150–300 ms | Far-away users need edge caching or a regional deployment |
| Shortcut | Value | Use |
|---|---|---|
| Seconds per day | 86,400 ≈ 10⁵ | Requests/day → QPS |
| 1M requests/day | ≈ 10–12 req/s | Sanity-check traffic claims |
| Peak factor | 2–3× daily cycle, 10×+ for sales and events | Design for the peak |
| 1 Gbit/s | ≈ 125 MB/s | Bits ↔ bytes |
| One app server | 100s to a few 1,000s simple req/s | Server count |
| One relational primary | 1,000s of simple queries/s | Replicas or sharding? |
| One cache node | 10,000s to 100,000s ops/s | Can a cache absorb the reads? |
Interactive simulation
Visual diagram
From users to numbers to design decisions, for StayHub at Karim's 10× plan: 300,000 guests a day.
Analogy
- Planning a weddingAbout 150 guestsPlanning a systemDaily active users
- Planning a weddingDrinks per guest per hourPlanning a systemRequests per second
- Planning a weddingEveryone wants a glass at the toastPlanning a systemPeak traffic
- Planning a weddingEnough waiters for that momentPlanning a systemCapacity for the peak
- Planning a weddingRoom size per guestPlanning a systemStorage per item
Where the analogy breaks: wedding guests come once. Data keeps piling up, so storage estimates must include how many years you keep it.
Check your understanding
Practice ladder
Check Theo's search estimate
Estimation Warm-upTheo from the Search team sends his estimate for the 10× plan:
300,000 guests/day × 6 searches each = 1,800,000 searches/day 1,800,000 ÷ 86,400 = 20.83 searches/s Each search: 4 ms in Redis + 25 ms in PostgreSQL Conclusion: 21 searches/s, one PostgreSQL handles it easily, nothing to do.
Trace his reasoning step by step. Which numbers are right, what's missing, and does his conclusion change once you fix it? (Today's sale emails bring a 10× peak; a search runs one PostgreSQL query on a cache miss, and 30% of searches miss.)
Fill in the chat estimate
Estimation PracticeMaya wants guests to chat with hotels. Lina started the estimate for the 10× plan and left two lines empty. Fill in storage and so what.
- Assumptions: 25,000 bookings/day; 40% of bookings start a chat; each chat has ~12 messages of ~300 bytes; keep messages 2 years; ×3 for indexes and a replica.
- Traffic: 25,000 × 40% × 12 = 120,000 messages/day ≈ 1.2 msg/s average; evening ×3 ≈ 4/s.
- Storage: ___
- So what: ___
Room photos from partners at 10×
Estimation PracticeAt 10×, StayHub has 18,000 partner hotels. Each uploads ~40 photos (originals ~2 MB). For every photo, StayHub stores the original plus 3 resized versions totalling ~400 KB. Guests open 1.2M hotel pages a day, each loading 8 photos of ~200 KB. The daily peak is 3× the average.
Estimate total photo storage and the peak photo bandwidth (in MB/s and Mbit/s). Then say what each number means for the design.
Shard before the round?
Decision StretchA new senior hire proposes sharding the bookings database across 4 PostgreSQL servers "before the funding round, so we're never caught out". It would take the Booking team about a quarter.
Facts from the 10× estimate: - ~30 writes/s at the sale peak; ~1,200 simple reads/s, mostly served by the replica. - Bookings data ≈ 27 GB/year with indexes. - One primary handles thousands of simple queries a second.
Write the decision: "We chose X over Y because…, accepting the risk of…", and add the trigger that would make you revisit it.
Explain it yourself
Walk a teammate through estimating the load of a new feature, and explain how the numbers lead to a design decision.