Back-of-Envelope Estimation (QPS, Storage, Bandwidth, Servers)

• Back-of-envelope estimation : the practice of quickly computing approximate system scale using simple arithmetic and well-known reference numbers.
• QPS (queries per second) : daily volume divided by 86,400 seconds, multiplied by a peak factor, giving the request rate the system must sustain.
• Storage : record size multiplied by record count multiplied by retention period, giving the total bytes the system must hold.
• Bandwidth : payload size multiplied by peak request rate, giving the network throughput leaving the servers.
• Server count : peak load divided by per-server capacity, plus a redundancy buffer, giving the minimum fleet size.

What is back-of-envelope estimation?

Back-of-envelope estimation is the practice of quickly computing the approximate scale of a system using simple arithmetic and a handful of well-known reference numbers. It is done early in a system design interview so that every architectural decision that follows is grounded in real numbers rather than guesswork. The key is speed and direction, not precision : you want to know whether you need ten servers or a thousand, not whether you need exactly forty-seven.

How do you estimate QPS?

The first quantity you estimate is queries per second. You take the total daily volume and divide by the number of seconds in a day, which is 86,400, and for speed everyone rounds that to 100,000. So one million requests a day is roughly 12 per second, and a hundred million a day is roughly 1,200 per second. You then multiply the average by a peak factor, usually between 2 and 10, because traffic is never flat.

package com.bank.estimation;

public class QpsEstimation {
    public static void main(String[] args) {
        long dailyRequests = 100_000_000L;     // 100 million/day
        long secondsPerDay = 86_400L;
        long avgQps  = dailyRequests / secondsPerDay;   // about 1157
        long peakQps = avgQps * 5;                       // about 5787

        System.out.println("Average QPS: " + avgQps);
        System.out.println("Peak QPS:    " + peakQps);
    }
}

Average QPS: 1157
Peak QPS:    5785

How do you estimate storage?

The second quantity is storage. You multiply the size of one record by the number of records created per day by the number of days you must retain the data. For a banking transaction record of about 300 bytes, ten million transactions a day for seven years is a very large number, so you reduce it to round powers of ten.

package com.bank.estimation;

public class StorageEstimation {
    public static void main(String[] args) {
        long bytesPerTxn   = 300L;
        long txnsPerDay    = 10_000_000L;
        long retentionDays = 7L * 365L;   // 7 years
        long totalBytes    = bytesPerTxn * txnsPerDay * retentionDays;
        double totalTB     = totalBytes / 1e12;

        System.out.println("Total storage: " + totalBytes + " bytes");
        System.out.printf("Approximately:  %.1f TB%n", totalTB);
    }
}

Total storage: 7665000000000 bytes
Approximately:  7.7 TB

How do you estimate bandwidth?

The third quantity is bandwidth, which is simply payload size multiplied by request rate. If each statement response is 200 kilobytes and you serve 6,000 per second at peak, that is more than one gigabyte per second leaving your servers, which tells you immediately that you need a content delivery network and compression.

package com.bank.estimation;

public class BandwidthEstimation {
    public static void main(String[] args) {
        long payloadBytes = 200 * 1024L;   // 200 KB per response
        long peakQps      = 6_000L;
        long bandwidthBps = payloadBytes * peakQps;
        double bandwidthGbps = bandwidthBps / 1e9;

        System.out.printf("Peak bandwidth: %.1f GB/s%n", bandwidthGbps);
        System.out.println("Verdict: CDN + compression required");
    }
}

Peak bandwidth: 1.2 GB/s
Verdict: CDN + compression required

How do you estimate server count?

The fourth quantity is server count. You divide peak load by what a single server can handle. A reasonable assumption is that one modern server handles about 1,000 simple requests per second, so 6,000 peak QPS means at least 6 servers, and you add buffer for redundancy, landing on perhaps 8.

package com.bank.estimation;

public class ServerEstimation {
    public static void main(String[] args) {
        long peakQps       = 6_000L;
        long qpsPerServer  = 1_000L;   // stated assumption
        long minServers    = peakQps / qpsPerServer;
        long withBuffer    = minServers + 2;  // N+2 redundancy

        System.out.println("Minimum servers: " + minServers);
        System.out.println("With buffer:     " + withBuffer);
    }
}

Minimum servers: 6
With buffer:     8

What reference numbers should you memorize?

A small set of reference numbers helps you estimate faster. Memory : a modern server has 64 to 256 GB RAM. Disk : an SSD reads at about 500 MB/s. Network : a data center link is 1 to 10 Gbps. A single-threaded server handles about 1,000 simple requests per second; with connection pooling and async IO, up to 10,000. One million seconds is about 11.5 days. One billion seconds is about 31.7 years. These let you convert units mentally without a calculator.

package com.bank.estimation;

public class ReferenceNumbers {
    public static void main(String[] args) {
        System.out.println("Seconds per day   : 86,400  (~100K)");
        System.out.println("Seconds per year  : ~31.5 million");
        System.out.println("1 KB              : 1,024 bytes");
        System.out.println("1 MB              : ~1 million bytes");
        System.out.println("1 GB              : ~1 billion bytes");
        System.out.println("1 TB              : ~1 trillion bytes");
        System.out.println("Simple QPS/server : ~1,000");
        System.out.println("SSD read speed    : ~500 MB/s");
    }
}

What are common mistakes in estimation?

The most common mistake is not stating assumptions. If you silently assume one server handles 1,000 QPS but the interviewer thinks you are assuming 10,000, your server count is off by ten times and nobody knows why. Always say your assumptions out loud. A second mistake is false precision : saying 1,157.407 QPS when 1,200 is better because it is easier to work with. A third mistake is forgetting the peak factor and designing for average load, which guarantees the system falls over during salary day.

package com.bank.estimation;

public class EstimationMistakes {
    // WRONG: hidden assumption, false precision
    // "We need exactly 1157.407 QPS and 6.13 servers."

    // CORRECT: stated assumption, round numbers
    // "I assume one server handles about 1000 QPS."
    // "Average is about 1200, peak about 6000."
    // "So we need about 6 servers plus 2 for redundancy = 8."
}

What should a senior engineer know?

A senior engineer knows that estimation is a communication tool, not a math test. The interviewer wants to see that you can reason about scale, catch impossible numbers early, and adjust your design accordingly. If your bandwidth estimate exceeds what a single data center can serve, that changes your architecture to include a CDN. If your storage estimate exceeds one database's capacity, that drives your sharding decision. Every estimate should lead to an architectural implication stated out loud.