back-of-the-envelopelisted

# 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 estim