Back Of The Envelope Agent Skill

Back-of-the-Envelope Estimation (BOTEC)

Turn vague scale ("high traffic", "huge data") into a few concrete numbers that

*decide the design*. BOTECs are quick, approximate calculations — feasibility

checks, not precision. The point is the process and directional correctness:

they tell you when a single database won't do, when caching is forced, when a

write spike needs a queue.

> A design for 1k QPS and one for 1M QPS are different systems. 10 GB fits in

> RAM; 10 TB needs distributed storage. Estimate first, choose second.

When to reach for this

At step 2 of any design (right after requirements), and any time a choice depends

on scale: sizing the read vs write path, deciding sharding vs a single node,

justifying a cache, or sanity-checking a proposed component against load.

When NOT to

Don't chase precision or model every microservice — that's the opposite of the

technique. Don't estimate what won't change a decision (YAGNI). Round

aggressively: "99,987 / 9.1" is "100,000 / 10". Always label units and

write assumptions down.

Clarify first

Estimates are only as good as their inputs. Pin down:

• DAU/MAU and what fraction is active daily.
• Actions per user per day (posts, reads, messages…).
• Read:write ratio — which path dominates.
• Object sizes — per record and per media blob.
• Retention — how long data is kept (drives total storage).
• Peak factor — peak is typically ~2× average; spikier for some workloads.

The core estimations (recipes)

Work each as a single multiply/divide chain. Full worked numbers and the CPU-time

derivation are in references/estimation-recipes.md.

• QPS = DAU × actions_per_user_per_day ÷ 86,400. Peak QPS ≈ 2 × QPS

(state your peak factor).

• Storage/day = writes_per_day × avg_object_size. Total =

storage/day × retention_days (watch base-10 vs base-2; storage is sold base-10).

• Bandwidth = QPS × payload_size (separate read and write; egress usually

dominates and costs money).

• Number of servers = peak_QPS ÷ per_server_QPS. Use the per-server rates

below as the divisor.

• Concurrent connections / memory = concurrent_users × per_connection_cost;

check the working set fits RAM (else it's an IO-bound, disk-backed design).

Numbers that matter

These are the reference points to *know*, so you can estimate without lookups.

Full tables (latency, server specs, request types, powers of two, nines) live in

references/numbers-to-remember.md — load it when you need a specific figure.

The two that drive most decisions:

| What | Rule of thumb |

|---|---|

| Single SQL/RDBMS node | ~1,000 QPS |

| Key-value store node | ~10,000 QPS |

| Cache server (Redis/Memcached) | ~100,000–1M QPS |

| One modern CPU core | ~1,000 simple requests/s → a 64-core box ≈ 64k req/s |

| Read 1 MB: memory vs SSD vs disk | ~μs vs tens–hundreds of μs vs ms (memory ≫ SSD ≫ disk) |

Think in orders of magnitude, not exact values. CPU-bound work is ~1×,

memory-bound ~10×, IO-bound ~100× the time. That ratio, not the decimals, is what

shifts an architecture.

Dos and don'ts

Distilled from the recipes and the ways estimates mislead.

Do

• Do round to one significant figure and reason in orders of magnitude — the

ratio (1× / 10× / 100×) is what shifts an architecture, not the decimals.

• Do size on peak, not average. State the peak multiplier (≈2× is a common

default; spikier for bursty workloads) before picking capacity.

• Do estimate reads and writes separately — a 95% read ratio and a write

spike pull the design in opposite directions.

• Do label units and write assumptions down, so a "GB" isn't ambiguous and

the chain can be re-checked when an input changes.

Don't

• Don't carry false precision. Decimals imply a confidence the inputs don't

support; "99,987" is "100,000".

• Don't trust per-server rates as universal. "1k QPS for SQL" is a

point-query rule of thumb; range scans, joins, and fat payloads can be 10×

worse — use it for the order of magnitude, then validate with real benchmarks.

• Don't conflate base-2 and base-10. RAM is base-2; storage/network marketing

is base-10 — close enough for an estimate, but only if the units are stated.

• Don't compute what won't change the decision. If a number doesn't move the

architecture, skip it (YAGNI).

Diagram

Estimation is usually a table, not a picture — keep the numbers and assumptions

inline. When a derived number forces a structural change (e.g. "300k QPS > single

DB → shard / add replicas"), that belongs in the architecture diagram itself; use

the architecture-diagram skill when drawing the design those numbers justify.

Related building blocks

• requirements-scoping — *depends on* it for the inputs (DAU, action rates, ratios, SLAs) this skill turns into numbers.
• data-storage — *feeds into* it: the storage totals and shard counts computed here drive its SQL/NoSQL and partitioning choices.
• caching — *feeds into* it: a high read ratio or hot working set sized here is the case *for* a cache.
• scaling-evolution — *feeds into* it: when an estimate crosses a per-node ceiling, that ceiling is the next bottleneck to plan around.
• system-design — *owned-concept lives here for the reasoning loop*; this is the orchestrator that calls this skill at step 2.

References

• references/numbers-to-remember.md — the cheat sheet: latency table, typical server spec, per-server QPS rates, CPU/memory/IO-bound request types, powers of two, availability nines. Read when you need a specific figure.
• references/estimation-recipes.md — worked examples (Twitter-scale QPS + storage, the 64-core→64k req/s CPU-time derivation, bandwidth and server-count sizing). Read to see a full chain end to end.

Scripts

For a deterministic check of a sizing chain (the one place exact arithmetic earns

its keep), run the calculator rather than doing it by hand:

• scripts/botec.py — python3 scripts/botec.py --dau 150e6 --actions 2 --peak 2 --obj-bytes 1e6 --media-frac 0.10 --retention-days 1825 --server-qps 1000 --json → QPS, peak, storage/day & total, bandwidth, server count. Per-server-QPS defaults mirror the rules of thumb above (override with --server-qps).
• scripts/test_botec.py — asserts the calculator matches expected_outputs/twitter_scale.json (the worked Twitter example), so the prose recipe and the math can't drift.