Back-of-Envelope Estimation
Back-of-the-Envelope Estimation is the practice of using quick, rough mental math to calculate a system's scale, storage, throughput, and hardware requirements before writing a single line of code.
In system design, these quick calculations stop you from over-engineering or picking the wrong architecture. For instance, they tell you immediately whether a single Postgres server on an EC2 instance can handle the load, or if you need an auto-scaled cluster of Cassandra shards backed by a global Redis cache tier.
1. The Developer's Cheat Sheet (Powers of 2 and 10)
To estimate numbers in your head within seconds, map data sizes to standardized numbers:
| Power of 2 | Exact Value (Bytes) | Approximation | Memory Type / Term |
| $2^{10}$ | $1,024$ | $1\text{ Thousand}$ | $1\text{ Kilobyte (KB)}$ |
| $2^{20}$ | $1,048,576$ | $1\text{ Million}$ | $1\text{ Megabyte (MB)}$ |
| $2^{30}$ | $1,073,741,824$ | $1\text{ Billion}$ | $1\text{ Gigabyte (GB)}$ |
| $2^{40}$ | $1,099,511,627,776$ | $1\text{ Trillion}$ | $1\text{ Terabyte (TB)}$ |
| $2^{50}$ | $1,125,899,906,842,624$ | $1\text{ Quadrillion}$ | $1\text{ Petabyte (PB)}$ |
2. Calculating Throughput (QPS / RPS)
When sizing an API, you need to calculate Queries Per Second (QPS).
The Golden Rule for Time Conversion
There are exactly $86,400$ seconds in a single day. For easy mental math, round this number to $100,000$.
Example Calculation Workflow:
Say your application scales to 10 Million Daily Active Users (DAU), and an average user performs 20 actions (like viewing a feed or posting a status) per day.
$\text{Total Requests per Day} = 10\text{M DAU} \times 20\text{ actions} = 200\text{ Million requests/day}$
$\text{Average QPS} = 200,000,000 \div 100,000 \approx \mathbf{2,000\text{ QPS}}$
$\text{Peak QPS} = \text{Average QPS} \times 2 \approx \mathbf{4,000\text{ QPS}}$ (Traffic is never flat; always assume a multiplier of 2 to 5 for peak traffic hours).
3. Calculating Storage Capacity
Once you know the incoming volume, estimate how much hard drive or database space you will consume over a standard 5-year retention window.
Example Calculation Workflow:
Using the same system above, assume $10\%$ of those 200 Million daily requests are text posts ($20\text{ Million posts/day}$). Each text post payload averages $500\text{ Bytes}$ of metadata (text, timestamps, user IDs).
$\text{Storage per Day} = 20,000,000 \text{ posts} \times 500\text{ Bytes} = 10,000,000,000\text{ Bytes} = \mathbf{10\text{ GB/day}}$
$\text{Storage per Year} = 10\text{ GB/day} \times 365\text{ days} \approx \mathbf{3.65\text{ TB/year}}$
$\text{5-Year Storage Planning} = 3.65\text{ TB} \times 5 \approx \mathbf{18.25\text{ TB}}$
4. System Hardware Realities (The Latency Numbers)
To translate your QPS and storage numbers into actual cloud infrastructure specifications, compare your results against real-world hardware performance barriers:
A. Storage Media Speeds (Read/Write)
RAM: $\sim 10\text{ to }30\text{ GB/s}$ access speeds.
NVMe SSD: $\sim 1\text{ to }4\text{ GB/s}$ sequential read/write.
Standard SATA SSD: $\sim 500\text{ MB/s}$ read/write.
Traditional Magnetic HDD: $\sim 100\text{ MB/s}$ (Highly vulnerable to slow seek times for random access).
B. Network Bandwidth Capacity
Standard Cloud VM Link: $1\text{ Gbps to }10\text{ Gbps}$ ($\sim 125\text{ MB/s to }1.25\text{ GB/s}$ network throughput ceiling).
The Bandwidth Formula: If your app serves large files (like images or video clips), multiply your Peak QPS by the average file size to make sure your network link won't max out.
5. Interview & Architectural Application
During an architectural design breakdown, these numbers dictate your entire strategy:
If your calculation shows your daily working data set fits within under $64\text{ GB}$, you can cache the entire active system state in a single standard Redis instance's RAM.
If your write traffic exceeds $10,000\text{ QPS}$, a single relational SQL database node will struggle to write to disk fast enough. This tells you immediately to implement a Message Queue for load leveling or to shard your database horizontally from day one.