Back-of-the-Envelope Estimation for System Design

You either buy far more machines than you need, or the system falls over at its busiest hour, and you cannot tell which until users complain. Back of the envelope estimation replaces the guess with ten minutes of rough maths, before anyone buys a server or writes code.

Picture a common setup. A photo-sharing app serves families and small creators across India. Grandparents post wedding albums, cousins share festival pictures and home bakers show off new cakes. The setup is made up, but the problem is real.

Two weeks before Diwali, the product team plans a shared Diwali album, where a whole family adds photos to one album on the festival night. Marketing expects a big jump in visits.

That gives the backend team two questions. Will the app stay up on Diwali night? And how much storage should the team book for next year, before the cloud bill surprises everyone?

Last year the team guessed. They added servers in a panic at 9 pm on Diwali, and photos took 20 seconds to open for an hour. This year the backend lead opens a notepad instead of a dashboard.

Fifteen minutes later the team has rough answers, and one of the two questions turns out to be the wrong worry. This guide rebuilds that notepad line by line, with every number you need to do the same.

Back-of-the-envelope estimation is rough maths, done with rounded numbers, that tells you the size of a system: how many requests, how much data and how many machines. The name means it fits on the back of any envelope.

Think about repainting your flat before Diwali. You do not ask the paint shop for an exact quantity. You measure each wall roughly, multiply length by height, subtract the doors and windows, and multiply by two coats.

The tin says how much wall one litre covers, say 10 square metres for one coat. Divide your total area by that, round up to whole tins and buy one spare. Now you know whether you need 4 tins or 40.

System estimation follows the same pattern. Users and their actions are the wall area. Copies of your data are the coats. What one server can handle is the coverage per litre. Spare servers are the extra tin.

Where the picture breaks: paint goes on at whatever pace you like, but traffic does not arrive evenly. A system has to survive its busiest minute, and a wall has no rush hour. The peak factor below handles that.

Five terms carry the rest of this guide. Each one comes with the photo app's number.

• Daily active users (DAU): the number of different people who open the app on a given day. The photo app has about 20 lakh (2 million) daily active users.
• Requests per second: how many requests reach your servers each second. Many people call it QPS, short for queries per second, and mean the same thing.
• Peak and peak factor: the peak is the busiest stretch of the day. The peak factor says how many times busier it is than the daily average. The app's 8 to 10 pm peak runs about three times the average.
• Latency and bandwidth: latency is how long one request takes, from asking to getting the answer. Bandwidth is how much data a link carries each second, counted in bits. A 1 Gbps link carries a billion bits each second.
• Order of magnitude: a factor of ten. 300 and 700 are the same order of magnitude. 300 and 30,000 are two orders apart, and that gap usually means a different design.

Every engineer should know two kinds of numbers: roughly how long basic operations take, and a few conversions, such as 86,400 seconds in a day. With both, you can size most systems in minutes.

The timing numbers come from a famous list. Peter Norvig's essay Teach Yourself Programming in Ten Years has a table of approximate timings on a typical PC. A GitHub gist titled Latency Numbers Every Programmer Should Know credits Jeff Dean of Google and, originally, Norvig. Its table is headed Latency Comparison Numbers (~2012).

A nanosecond is a billionth of a second. A microsecond is a thousand nanoseconds, and a millisecond is a thousand microseconds. Here are the gist's entries that matter most for everyday design.

An SSD is a solid-state drive, storage with no moving parts. A hard disk has a spinning platter, and a seek is the time its arm takes to move to the right spot. RAM is the computer's main working memory.

The two published versions do not agree on every digit. Norvig's table gives a disk seek as 8 milliseconds, while the gist says 10. That is the right way to hold these values: as sizes, not specifications.

The diagram turns the table into a ladder. Read it from the top and watch the gaps between steps.

Four lessons fall out of this ladder, and each one shapes real designs.

• Memory is very fast. A memory read is thousands of times faster than a data centre round trip, which is why a cache, recent data kept in memory, pays off so well.
• Reading in order beats jumping around. By the gist's numbers, one hard disk seek costs as long as reading half a megabyte in order.
• One hop inside a data centre is cheap, about half a millisecond. But a page that makes 50 such calls one after another has already spent 25 milliseconds.
• Crossing an ocean costs about 150 milliseconds there and back, and a faster server does not shorten the distance. The fix is to put data closer to users.

How the numbers have moved since 2012

These values are not fixed. Colin Scott, a researcher, built an interactive chart that projects the list year by year from hardware trends. Its code holds a random SSD read at 16 microseconds for every year after 2014.

That is about a tenth of the gist's 150 microseconds. The same code keeps a memory read at 100 nanoseconds after 2000. It keeps the data centre round trip at half a millisecond and the ocean trip at 150 milliseconds in every year.

When we checked in October 2026, the gist had also gained rows, marked 2026, for generating text with large language models. This guide leaves them out, because the gist's own notes tie them to particular setups: model size, hardware, prompt and output length, and caching.

Conversions worth keeping in your head

The second set of numbers turns daily totals into per-second rates and bytes into bigger units. Keep this table near you while you practise.

Multiply daily active users by how often each one does the action, then divide by 86,400 seconds in a day. That gives the average. Multiply by a peak factor to get the busy-hour rate.

Start with the most common action on the photo app: opening a photo. Here is the notepad, line by line.

1. 1

   Start with users

   The app has 2 million daily active users. Sign-ups do not count: the app has 1.5 crore (15 million) accounts, but most do not open it on a given day.

2. 2

   Count actions per user

   An average user opens about 60 photos a day. That is 2 million times 60, or 120 million photo views a day.

3. 3

   Turn days into seconds

   120 million divided by 86,400 is about 1,400 views a second. Dividing by 100,000 instead gives 1,200, which is close enough for a first pass.

4. 4

   Add the evening peak

   The evening peak is about three times the average. So the app serves about 4,200 views a second between 8 and 10 pm.

5. 5

   Add the festival spike

   The product team expects Diwali night at three times a normal evening peak. That gives about 12,500 views a second for a few hours.

6. 6

   Do the same for writes

   Users upload about 1 million photos a day. That is about 12 uploads a second on average, and about 35 at the evening peak.

Each photo view also asks the app servers for the photo's details, such as its caption and where the file lives. So the app servers see about the same 4,200 requests a second at peak. The diagram shows the chain as boxes.

What just happened? Two daily totals became two rates. About 1,400 photo views a second against about 12 uploads a second is a ratio of about 120 to 1. The app is read-heavy, so caching and fast photo delivery matter far more than write speed.

For storage, multiply new items per day by the size of each item, then by days kept and by copies. For bandwidth, multiply requests per second by the bytes in each response, then by 8 to get bits.

Pause and predict: Diwali night brings three times the evening traffic. Which of the two questions does the festival really threaten, servers or storage? Hold your guess until the end of this section.

Storage for the photos

A phone photo on the app is about 3 MB. The app also saves smaller resized copies for albums and previews, about 0.5 MB in total. So each upload needs about 3.5 MB.

One million uploads a day times 3.5 MB is 3.5 TB a day. Over a year that is about 1,280 TB, or roughly 1.3 petabytes (PB). A petabyte is a thousand terabytes.

Now add the coats. If the storage keeps three full copies of every file for safety, the raw space is about 3.8 PB. Many storage services handle copies for you, but their cost is built into what you pay.

Storage for the facts about photos

Each photo also has metadata, the small facts about it: owner, album, time, caption and where the file lives. Allow about 1 KB per photo. That is 1 GB a day, or about 365 GB a year.

That number changes the design. The photos need a big file store that grows by petabytes. The metadata fits on one database machine for years. They belong in different places.

Bandwidth

Each photo view sends a resized photo of about 200 KB. At 1,400 views a second, that is 280 MB a second, or about 2.2 Gbps on average. The evening peak is about 6.7 Gbps.

On Diwali night it reaches about 20 Gbps. That much traffic should come from a CDN, a content delivery network: servers in many cities that keep copies of popular files near users.

Uploads are smaller. One million photos of 3 MB is 3 TB a day, or about 35 MB a second on average.

The estimate in Python

Put the notepad into a small function so the product team can change the inputs themselves. Views and uploads are per user per day. Photo size is in megabytes, view size in kilobytes, and peak is the peak factor.

SECONDS_PER_DAY = 86_400

def estimate(dau, views_per_user, uploads_per_user, photo_mb, view_kb, peak):
    reads_per_sec = dau * views_per_user / SECONDS_PER_DAY
    writes_per_sec = dau * uploads_per_user / SECONDS_PER_DAY
    storage_tb_per_day = dau * uploads_per_user * photo_mb / 1_000_000
    egress_gbps = reads_per_sec * view_kb * 8 / 1_000_000   # KB to gigabits
    return {
        "peak_reads_per_sec": round(reads_per_sec * peak),
        "peak_writes_per_sec": round(writes_per_sec * peak),
        "storage_tb_per_year": round(storage_tb_per_day * 365),
        "peak_egress_gbps": round(egress_gbps * peak, 1),
    }

print(estimate(2_000_000, 60, 0.5, 3.5, 200, peak=3))

Save it as estimate.py and run python3 estimate.py. On Python 3.13 it prints the line below. Units are requests a second, terabytes a year and gigabits a second.

{'peak_reads_per_sec': 4167, 'peak_writes_per_sec': 35, 'storage_tb_per_year': 1278, 'peak_egress_gbps': 6.7}

Two lines matter most. Dividing by SECONDS_PER_DAY turns daily totals into rates. Multiplying by 8 turns bytes into bits, because links are sold in bits per second.

Now check your prediction. What if uploads jump five times for three days around Diwali? That adds about 42 TB, around 3 percent of a year's growth. Storage is safe, so the real Diwali risk is the read peak.

Divide peak requests per second by what one server can handle while staying comfortably busy, round up, and add spares for failures. The per-server number must come from a load test of your own code.

A load test sends fake traffic at a server until it slows down. The app's test showed one app server handles about 1,000 metadata requests a second before replies get slow (made up). The team plans to run each server only half busy at peak.

import math

def servers_needed(peak_rps, rps_per_server, target_busy=0.5, spares=1):
    usable = rps_per_server * target_busy      # plan to run each server half busy
    return math.ceil(peak_rps / usable) + spares

print(servers_needed(4_167, 1_000))        # normal evening peak
print(servers_needed(4_167 * 3, 1_000))    # Diwali night, 3x the evening peak

Run it and the first call prints 10, the servers for a normal evening. The second prints 27 for Diwali night. The target_busy value leaves room for slow requests and uneven traffic, and spares covers one server dying at the worst moment.

Those 27 servers are close to three times today's 10, which answers the product team's first question. The team books them for three nights only, so the extra cost stays small.

The cache needs sizing too. Families mostly reopen today's and this week's photos, so a small share of photos gets most of the views.

Say about 20 million different photos are viewed on a busy day (made up). At 1 KB of metadata each, that is about 20 GB, which fits in the memory of one cache server. Memory reads take nanoseconds, so this keeps albums quick.

The next diagram is the question to ask about every number: does it fit on one machine? Follow the two arrows for the app's two kinds of data.

Google's site reliability engineers teach this habit as non-abstract large system design. Their workbook chapter first asks whether a basic design is possible and whether it can be better. Then it scales the design up and asks whether it is feasible, resilient and better still.

Its worked example designs a system that reports how often ads are clicked. It starts from 500,000 search queries a second and rounds each log entry up to 2 KB. That gives 86.4 TB of logs a day.

The chapter then rounds 86.4 TB up to 100 TB, and its sums show one machine cannot keep up. One version divides 100 TB by 64 GB of memory per machine and gets 1,563 machines. The design moves on to sharding, splitting the data across many machines.

Here is how the photo app's numbers sit in its design. Each box carries the estimate that sized it.

A load balancer is a server that spreads incoming requests across a group of servers. Viewed photos never pass through the app servers, and that one choice keeps up to 20 Gbps off them. Only uploads do, about 100 MB a second at the evening peak.

It needs to land in the right order of magnitude, ideally within two or three times the real value. The goal is to choose between designs, not to fill in an invoice.

Go back to the paint. Nobody measures walls to the millimetre. Being one tin short means a quick trip back to the shop. Being ten tins short means you planned for the wrong flat.

So round hard. Use 100,000 seconds in a day when the maths is in your head. Use 3 MB for a photo, not 2.87. Rounded numbers keep you fast and make mistakes easier to spot.

Write every assumption down next to the result. Then anyone can challenge one line, such as 60 views per user, without redoing the whole thing.

Finally, check the estimate against reality when you can. Once the app is live, its dashboard shows about 1,300 photo views a second on an average day (made up). The estimate said 1,400, so the rest of the notepad earns more trust.

The most common mistakes are mixing up units, sizing for the average instead of the peak, forgetting copies and metadata, and giving numbers with false precision. Each one is easy to catch once you know it.

• Mixing bits and bytes. A 1 Gbps link moves at most 125 MB a second, less the header bytes every packet carries, not 1,000. Write the unit next to every number.
• Counting every signed-up user as active. The app has 15 million sign-ups but 2 million daily users. That is like painting the doors and windows too.
• Sizing for the average. Servers that cope at 1,400 views a second can still fall over at 12,500.
• Forgetting the copies. Storing three copies is like a second and third coat: skip it and you run out halfway up the wall.
• Forgetting the small stuff. Thumbnails, metadata, logs and backups add up, even when each item is tiny.
• False precision. An answer like 4,166.67 requests a second suggests a certainty you do not have. Say about 4,200, and round servers up to whole machines.

Divide the share of the day's traffic that lands in the busy window by the share of the day that window covers. If the two evening hours carry a quarter of the day's views, the peak factor is 0.25 divided by 2/24, which is 3.

In the photo app, the two evening hours carry about a quarter of the day's views (made up), which is where its factor of three comes from. To find yours, pull one normal day of request counts per hour from your load balancer or access logs. Find the busiest window and do the division.

The window size matters. The busiest minute inside a two-hour window can only be equal to or busier than the two-hour average. So pick the window your system reacts in: if adding servers takes ten minutes, find the busiest ten minutes.

Known events need their own number. The festival multiplier of three over a normal peak is the product team's forecast, so write it down as an assumption and check it against last year's graph.

Errors in the inputs multiply, because the estimate is a product. If four inputs are each 1.5 times too high, the answer is 1.5 to the fourth power, about 5 times too high.

The photo app's Diwali view rate is such a product: users, views per user, peak factor and festival multiplier. All four can be optimistic together, for example when one hopeful launch plan inflated every one of them.

Independent errors are kinder, because some run high and some run low. We simulated 200,000 estimates where each of four inputs was off by a random factor between half and double, spread evenly on a log scale.

In that run, 60 percent of the answers landed within two times of the truth, and 92 percent within four times. About 5 in 1,000 were more than 8 times off, and none reached the worst possible case of 16 times.

So the order-of-magnitude goal is realistic when your guesses are honest and independent. It is not safe when one story drives several inputs at once. Check the two or three biggest inputs against real data first.

Multiply the arrival rate by the average time each request spends inside the system. This is Little's law, proved by John Little in 1961: the average number inside equals the arrival rate times the average time inside.

At the photo app's evening peak of about 4,200 requests a second, say each request takes 0.2 seconds from arrival to reply (made up). Then about 840 requests are inside the servers at any moment.

That number sizes things a request rate cannot. If each request ties up one worker thread, a slot that runs one request at a time, for its whole life, the fleet needs about 840 busy threads at peak. If it holds a database connection for only 20 milliseconds, about 84 connections are in use.

The law needs only averages over a steady stretch of traffic, not any particular pattern of arrivals. We checked it by simulating 4,200 random arrivals a second, each lasting 0.2 seconds on average. The average number inside came out at 839.

You can check it on a live server too. Over the same minute, compare the in-flight count your server reports with request rate times average latency. If they disagree by a lot, check that both are measured at the same place, such as the load balancer.

Because waiting time climbs steeply as a server gets busier. In the simplest queueing model, one server with random arrivals and random job lengths, average time inside is the job time divided by one minus the busy share.

The busy share is called utilisation. At 50 percent utilisation, a request spends twice its own work time inside on average. At 90 percent, it spends ten times. Our simulation of 400,000 requests matched each figure within 3 percent.

Real servers are not this simple model. In our simulations, both steadier job lengths and several workers sharing one queue gave shorter waits at the same utilisation. Treat the table as a shape: the last stretch of capacity is where waits climb fastest.

That is why servers_needed plans for half busy. At the normal evening peak, 10 servers each run about 42 percent busy. If one dies, the other nine run about 46 percent busy, still on the gentle part of the curve.

Because a terabyte (TB) is 10 to the power 12 bytes, while many tools count in binary units, where one GiB is 2 to the power 30 bytes. One terabyte is about 931 binary gigabytes (GiB), and some tools label that with a plain G. The numfmt command-line tool from GNU coreutils prints 932G when given --to=iec.

NIST, the US standards agency, lists the binary prefixes kibi, mebi, gibi and tebi, written KiB, MiB, GiB and TiB. It says the IEC, the international electrical standards body, approved them in December 1998. One KiB is 1,024 bytes, while one kB is 1,000.

The gap grows with each step: about 2.4 percent at kilo, 7.4 percent at giga, 10 percent at tera and 12.6 percent at peta. The photo app's 1.28 PB a year is about 1.13 PiB.

All the sizes and link speeds in this guide are decimal: 1 Gbps here means a billion bits a second. You can check the disk gap yourself with two commands.

numfmt --to=iec-i --format=%.2f 1000000000000
python3 -c "print(10**12 / 2**30)"

On GNU coreutils 9.4 the first line prints 931.33Gi. The second prints 931.3225746154785, the exact number of GiB in one TB. numfmt rounds away from zero by default, which is why it shows 931.33.

State your assumptions out loud, round hard, and work out requests per second, storage and bandwidth in that order. Then say what each number means for the design.

Interviewers care less about the exact value than about turning a vague product into numbers, and numbers into choices. This plan fits in about five minutes.

1. 1

   Ask for the scale

   Ask how many daily users there are and what they mostly do. If the interviewer says pick something, choose a round number and say it clearly.

2. 2

   Find the read-to-write ratio

   Estimate reads and writes separately. A ratio like 100 to 1 tells you caching and a CDN matter most.

3. 3

   Get the peak requests per second

   Divide daily totals by about 100,000 seconds, then multiply by a peak factor. Say where the factor comes from, or state 2 to 3 as an assumption.

4. 4

   Size storage for a few years

   Items per day times size, times 365, times the years you keep data. Mention copies and metadata separately.

5. 5

   Size bandwidth

   Requests per second times response size, times 8 for bits. Say which part a CDN can carry.

6. 6

   Tie each number to a choice

   One database or many? Cache or no cache? One region or several? Each answer should point back to a number you wrote.