Back-of-the-Envelope Calculations

Basic System Design
≈ 3 min read

Back-of-the-envelope means quickly estimating the order of magnitude

A rough calculation is useful when you want to test an idea before detailed design. We take a few understandable assumptions, round the numbers, and estimate the scale of the system in a few steps. The goal is not an exact forecast, but an answer such as “hundreds of RPS or hundreds of thousands?” and “gigabytes or petabytes?”

Start with a small set of inputs

Suppose we are designing a service where users publish small images. A first pass needs only a few quantities.

DAU = 20,000,000
uploads_per_user_per_day = 0.2
reads_per_user_per_day = 20
average_image_size = 500 KB
peak_factor = 5

There is no need to introduce dozens of factors immediately. Every new parameter should help make a decision, not merely make the calculation look more sophisticated.

Step 1. Estimate writes and reads

20 million users at 0.2 uploads each produce about 4 million new images per day. That is roughly 46 average writes per second. Reads are much more frequent: 400 million per day, or about 4,600 average RPS.

writes/day = 20,000,000 × 0.2 = 4,000,000
average_write_RPS ≈ 4,000,000 ÷ 86,400 ≈ 46

reads/day = 20,000,000 × 20 = 400,000,000
average_read_RPS ≈ 400,000,000 ÷ 86,400 ≈ 4,600

At this point, we can already see that the system is far more read-heavy than write-heavy. That is not an architecture decision yet, but it is an important signal for later design work.

Step 2. Add the peak

If we assume a peak five times above average, the read path should handle roughly 23,000 RPS. This is much more useful for capacity reasoning than the daily average alone.

peak_read_RPS ≈ 4,600 × 5 ≈ 23,000

Step 3. Estimate storage growth

With an average image size of 500 KB, raw data grows by about 2 TB per day. Over a year, that is roughly 730 TB before additional copies and storage overhead.

4,000,000 images/day × 500 KB ≈ 2 TB/day
2 TB/day × 365 ≈ 730 TB/year

Step 4. Check network traffic

If a read returns the same 500 KB on average, the average outbound flow at 4,600 RPS is about 2.3 GB/s. During the peak period, it may be roughly five times higher.

4,600 reads/s × 500 KB ≈ 2.3 GB/s
peak_egress ≈ 11.5 GB/s

What to do with the result

We now have more than the vague statement “there are many users.” We have several technical reference points: tens of writes per second, tens of thousands of peak reads, hundreds of terabytes of new data per year, and gigabytes per second of network traffic.

These numbers do not choose the architecture automatically. They provide the scale against which system components can be discussed and help us check whether a simple solution is sufficient or would hit its limits too early.

If a rough calculation changes an architecture decision, it has already done its job. Precision can be improved later when real metrics and concrete component limits become available.