Back-of-the-Envelope Estimation

Back-of-the-envelope estimation is rough arithmetic that gives the order of magnitude of a system's load and data. It answers structural questions: whether one machine can serve the traffic, whether data fits on one disk, whether a cache is worthwhile, and how many servers are needed. Precision is not the goal. A result within a factor of two or three is sufficient when it decides between designs.

Powers of two and data sizes

Typical object sizes used in estimates: a character in ASCII is 1 byte; a 64-bit integer is 8 bytes; a UUID is 16 bytes in binary; a short text record is 100 bytes to 1 KB; a compressed photo is a few hundred KB to a few MB; a minute of compressed video is on the order of several MB to tens of MB depending on quality.

Latency numbers

Widely cited orders of magnitude (hardware varies, treat as approximate):

Conclusions that follow from the numbers:

• Memory is roughly 1,000 times faster than SSD for random access and about 100,000 times faster than a disk seek.
• Sequential access is much cheaper than random access on all media.
• Network calls within a data center cost far more than local memory access; cross-region calls cost far more again.
• Compress data before sending it across a network when CPU is cheaper than bandwidth.

Time conversions

• 1 day = 86,400 seconds, rounded to about 100,000 (10^5) for mental arithmetic.
• 1 month is about 2.5 million seconds; 1 year is about 31.5 million seconds (about 3 x 10^7).
• Requests per second = requests per day / 86,400.

Network rates are quoted in bits per second and storage in bytes: 1 Gbit/s equals 125 MB/s, and 10 Gbit/s equals 1.25 GB/s.

Core formulas

Average QPS = requests per day / 86,400.

Peak QPS = average QPS x peak factor. The factor is an assumption (commonly 2 to 10) and must be stated.

Write QPS and read QPS = total QPS split by the read/write ratio.

Storage = records per day x bytes per record x retention days x replication factor.

Bandwidth = QPS x bytes per request, computed separately for incoming (ingress) and outgoing (egress) traffic.

Memory for a cache = working set size. A common assumption is that a fraction of items (for example 20 percent) receive most of the reads, so cache that fraction of the daily read data.

Servers needed = peak QPS / QPS one server can handle, rounded up, plus headroom and redundancy. Per-server capacity depends on the workload and must be assumed or measured.

flowchart TD
    U["Daily active users"] --> R["Requests per day"]
    R --> Q["Average QPS = /86,400"]
    Q --> P["Peak QPS = x peak factor"]
    P --> S["Servers = peak / per-server QPS"]
    R --> ST["Storage = records x size x retention x replicas"]
    P --> B["Bandwidth = QPS x payload"]

Worked example: photo sharing service

Assumptions: 100 million daily active users; each user views 20 photos per day and 1 in 10 users uploads one photo per day; average photo is 500 KB after processing; retention is 5 years; replication factor 3.

Reads. 100,000,000 x 20 = 2 x 10^9 views per day. Average QPS = 2 x 10^9 / 86,400, about 23,000. With a peak factor of 3, about 70,000 QPS.

Writes. 100,000,000 / 10 = 10 million uploads per day. Average QPS = 10^7 / 86,400, about 116.

Storage. 10^7 photos x 500 KB = 5 x 10^12 bytes = 5 TB per day. Over 5 years (1,825 days): about 9.1 PB. With replication factor 3: about 27 PB. This exceeds any single machine and requires distributed object storage.

Egress bandwidth. 23,000 QPS x 500 KB = 11.5 GB per second on average, This is about 92 Gbit per second (11.5 GB x 8 bits), roughly nine 10 Gbit/s network interfaces at full utilization even at the average rate, so a CDN is required to serve the images from the edge.

Servers. If one application server handles about 1,000 read requests per second (an assumption), 70,000 peak QPS needs 70 servers, and about 90 to 100 with headroom and redundancy for failures.

Cache. Assume the hot set is the photos uploaded in the last day, 5 TB. Caching 20 percent of that, 1 TB, fits in the memory of a small cluster of cache nodes, and the CDN caches the rest of the popular images at the edge.

Worked example: chat messages

Assumptions: 50 million daily active users, 40 messages sent per user per day, 100 bytes per message, retention 5 years, replication factor 3.

• Messages per day: 2 x 10^9. Average write QPS: about 23,000. Peak with factor 3: about 70,000.
• Storage per day: 2 x 10^9 x 100 B = 200 GB. Five years: about 365 TB. With replication 3: about 1.1 PB.

A wide-column or key-value store partitioned by conversation is a natural fit at this volume.

A small calculator in Java

The arithmetic is simple to script. This example reproduces the chat estimate.

public class Main {
    static double qps(double requestsPerDay) {
        return requestsPerDay / 86_400.0;
    }

    static double storageTb(double recordsPerDay, double bytes, double days, double replicas) {
        return recordsPerDay * bytes * days * replicas / 1e12;
    }

    public static void main(String[] args) {
        double messagesPerDay = 50e6 * 40.0;
        double avg = qps(messagesPerDay);
        double peak = avg * 3.0;
        double tb = storageTb(messagesPerDay, 100.0, 365.0 * 5.0, 3.0);
        System.out.printf("average QPS: %.0f%n", avg);
        System.out.printf("peak QPS: %.0f%n", peak);
        System.out.printf("storage with replication: %.0f TB%n", tb);
    }
}

average QPS: 23148
peak QPS: 69444
storage with replication: 1095 TB

Practical rules

• Round aggressively: use 100,000 seconds per day, powers of ten, and one significant digit.
• Write units next to every number to avoid mixing KB, MB, and Mbit.
• State assumptions aloud so the interviewer can correct them.
• Stop when the number changes a design decision. A result of 100 QPS means a single database is enough. A result of 100,000 QPS means caching and horizontal scaling are needed.
• Sanity check against known capacities: a single well-tuned relational database node commonly handles thousands to low tens of thousands of simple queries per second, and an in-memory cache node handles on the order of 100,000 operations per second. Exact figures depend on hardware and workload.

Interview questions

• Why divide daily requests by 86,400 and then multiply by a peak factor? Daily totals give the average rate. Capacity must handle the peak, which is higher than the average because traffic varies through the day, so a factor is applied.
• Why include the replication factor in storage? Every replica stores a full copy, so raw disk requirements are a multiple of the logical data size.
• How does an estimate change the design? It determines thresholds: whether data fits on one node, whether reads must be cached, whether egress must go through a CDN, and whether writes need partitioning.
• Why is the difference between memory and disk latency important? It explains why caches reduce latency by orders of magnitude and why designs avoid random disk access in hot paths.