The Estimation Method — A Repeatable 5-Step Routine

Estimation is a routine, not a talent

Freezing on “how many servers?” isn’t a knowledge gap — it’s the absence of a fixed procedure. Run the same five steps every time and the math falls out. Pair it with the cognitive-science Fermi method: decompose → estimate each piece → combine → bound.

The 5 steps (always in this order)

#	Step	What you write down
1	Inputs	DAU, actions/user/day, bytes/action, read:write ratio, retention (years)
2	QPS	= DAU × actions/day ÷ 86,400 → ×2–10 for peak
3	Storage	= writes/day × bytes/write × 365 × years × replication
4	Bandwidth	= QPS × bytes/payload
5	Servers / memory / cost	peak QPS ÷ per-server QPS; cache the hot 20%; price it

Three habits that make it fast and credible

• Separate the power-of-10 from the coefficient. Compute 6 × 10⁸, not 600,000,000. This is the single biggest speed-up.
• State every assumption out loud and round aggressively. Interviewers grade the process, not 3 decimal places.
• Bound it. Give a LOW (pessimistic) and HIGH (optimistic) estimate. If HIGH/LOW > 100×, one assumption is too loose — tighten it. This “bounds check” is your built-in sanity test.

Worked example — “Design Twitter” in 60 seconds

• Inputs: 300M DAU, 2 tweets/user/day, ~300 B/tweet, 5-yr retention.
• QPS: 300M × 2 = 6×10⁸ writes/day ÷ 10⁵ = ~6,000 writes/s → peak ×5 ≈ 30K/s.
• Storage: 6×10⁸ × 300 B × 365 ≈ ~65 TB/yr → 5 yrs ≈ ~330 TB.
• Reads ~100× writes → ~600K read QPS → this is why Twitter is a caching/fan-out problem.

Three memorized numbers (10⁵ s/day, 300 B/tweet, “round to powers of 10”) just produced a full capacity plan.

Second worked example — “YouTube comments,” carried through with bounds

• Inputs: 500M DAU, 2 comments/day, ~200 B/comment, 50:1 read:write, 3-yr retention.
• Write QPS: 500M × 2 ÷ 86,400 ≈ 11.6K writes/s; peak ×2–5 → 23–58K writes/s.
• Storage: 11.6K/s × 200 B × 86,400 × 365 × 3 yr ≈ ~220 TB before replication; ×2–3 → ~440–660 TB.
• Read bandwidth: 50 × writes ≈ 580K reads/s (≈2.9M/s at peak); at ~1 KB/read that is 0.6–2.9 GB/s → the design is read-and-cache dominated.
• Gate: >50K writes/s plus multi-GB/s reads → shard by videoId, cache top comments, fan-out popular videos.

Common mistakes

• Estimating to three significant figures — interviewers grade the process, not the precision.
• Skipping the bounds check; if HIGH/LOW spans >100×, one assumption is unanchored.
• Skipping the decision gate — an estimate with no architectural consequence is arithmetic theater.
• Sizing off registered users instead of DAU — inflates every number 5–10×.

When the routine misleads

The five steps are mechanical; the judgment is knowing when their output is a lie. Two failure modes matter.

Top-down and bottom-up disagree — trust the binding constraint. Estimate the same quantity two ways. Top-down starts from an aggregate: for a ride-share, 1.5B smartphone users in target markets × 2% adoption × 3 rides/week ÷ 7 ≈ 13M rides/day (~150 rides/s). Bottom-up builds from unit supply: 200 cities × ~500 active drivers × 20 rides/driver/day ≈ 2M rides/day (~23 rides/s). They differ ~6× — so one assumption is wrong, and “average them” is the wrong move. Ask instead which side is a physical constraint: rides are gated by driver supply (you cannot complete more rides than drivers can drive), so the bottom-up number is a real ceiling and the top-down 13M is aspirational demand. When one estimate is supply-constrained and the other demand-constrained, the binding (smaller, physical) constraint wins — size for it, and treat the gap as growth headroom, not launch load.

Compute only to the precision the nearest gate demands. An estimate matters only where it flips a design decision (see Decision Gates). The single-primary write ceiling sits near ~50K writes/s, so an estimate of 4K or 400K writes/s needs no refinement — you are nowhere near the gate. But the YouTube-comments example above lands at 23–58K writes/s once the peak factor is applied, and that range straddles the ~50K shard gate: at peak ×2 (23K/s) one primary copes; at peak ×5 (58K/s) you must shard. Here the ×2-vs-×5 assumption is the architecture decision — so this is exactly where you stop rounding and go measure the real peak factor. Precision is worthless far from a gate and decisive next to one.

The next pages are per-resource playbooks for steps 3–5. Practice them in the drills at the bottom of this topic.

---

Formulas are standard/public-domain engineering math. Approach and reference-table format adapted from the System Design Primer (CC BY 4.0), Jeff Dean’s latency numbers, the DesignGurus capacity-estimation guide, and Little’s Law.

I just read a lesson on **The Estimation Method — A Repeatable 5-Step Routine** (System Design) and want to truly understand it. Explain The Estimation Method — A Repeatable 5-Step Routine from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **The Estimation Method — A Repeatable 5-Step Routine** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **The Estimation Method — A Repeatable 5-Step Routine** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **The Estimation Method — A Repeatable 5-Step Routine** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.