Back of the Envelope Estimation

The name comes from an old habit. You grab the back of an envelope, scribble a few numbers, and get an answer that is close enough to decide something. Nobody checks it with a calculator. Nobody needs it to be exact.

In a system design interview this is the step where you work out how big the thing is. How many requests a second? How much data a year? Can one machine do it, or do you need a fleet?

Many beginners fear this step because they think the math must be perfect. It does not. If the real answer is 4,300 and you say 5,000, you are fine. If the real answer is 4,300 and you say 50,000, that is a problem. You are aiming for the right number of zeros.

Why bother

Say someone asks you to build a bridge. First question: is it for walkers or for trucks? A rope bridge and a highway bridge are not the same job, and the cost differs by a factor of a thousand.

Software is the same. A service with 50 requests a second runs on one small server. A service with 50,000 a second needs many servers, a cache, and a database that is split into pieces. The estimate tells you which of those two jobs you have. That is all it is for.

The small set of numbers to know

You need a short list in your head. Not a hundred facts. About ten.

Powers of two and ten

Computers count in powers of two, people count in powers of ten, and the two are close enough to be used together.

So every step up (KB to MB to GB to TB) is about 1,000 times bigger. That is the only rule you really need. When you do the math, treat 1 KB as 1,000 bytes, not 1,024. You will be off by 2 to 5 percent and nobody cares.

The cheat sheet

QPS means queries per second, or just "requests per second". It is the number of times per second someone knocks on your door.

The two lines at the bottom are the most useful. A million actions a day sounds like a lot, but spread across the day it is only about 10 a second. A billion actions a day is about 10,000 a second. If you remember only those two, you can already do half of any estimate.

Rounding on purpose

A day really has 86,400 seconds. We use 100,000. That is a 15 percent error, and we picked it because dividing by 100,000 is just moving a decimal point. You can do it in your head while talking.

This is the idea behind the whole technique: round early, round on purpose, and always in a direction that keeps the math easy.

• 86,400 becomes 100,000.
• 365 days becomes 400, or 300. Use whichever is easier, but say so.
• A 1.8 MB photo becomes 2 MB.
• 3.3 million becomes 3 million.

Each rounding is small. The final answer is still within a factor of two of the truth, and that is the precision we need. When you round, say it out loud: "I will round a day to 100 thousand seconds to keep it simple." Interviewers like hearing that. It shows you know it is a rounding and not a mistake.

One more tip. Write numbers with their units all the way through. "2 million photos x 2 MB = 4 million MB = 4 TB". When the units are written down, you almost never lose a factor of 1,000 by accident, and that is the most common slip.

The recipe

Almost every estimate follows the same steps.

1. Start from daily active users (DAU). That is the number of people who use the product on a normal day.
2. Pick how many times each user does the main actions per day. Reads and writes separately.
3. Multiply to get actions per day. Divide by 100,000 to get per second.
4. Multiply by 2 or 3 to get peak per second.
5. Take the size of one item. Multiply by items per day for storage per day. Multiply by about 400 (or 365) for storage per year.
6. Take size per request times requests per second to get bandwidth.
7. Divide peak QPS by what one machine can do to get the number of servers.
8. Write down what it means for the design.

Let us go through each piece before the full examples.

Read and write ratio

Most products read far more than they write. On a photo site, many people look at photos and few upload. On a news site, one article is written once and read a million times. The ratio tells you what to optimise.

• Reads far bigger than writes (100 to 1 or more): caches, copies of the database, a CDN (a network of servers close to users that holds copies of files). Reads can be made cheap.
• Writes close to reads or bigger (a chat app, a logging system): caches help much less. You worry about how fast you can write and how to split the data.

If the interviewer gives no ratio, pick one and say it. "I will assume 100 reads for every write." A photo app or a link shortener is often 100 to 1 or more. A chat app is close to 1 to 1.

Storage per year

Storage is simple. Size of one item, times items per day, times days.

storage per day  = items per day x size of one item
storage per year = storage per day x 400   (rounded up from 365)

Then keep going if the interviewer asks about 5 years. And remember copies: data is usually stored 3 times for safety, so real disk is about 3 times what you calculated. Mention this once, then ignore it so the math stays small.

Also separate the big stuff from the small stuff. A photo itself is 2 MB. The row in the database that says who uploaded it and when is about 1 KB. Those two live in very different places. Big files go in cheap file storage. Small rows go in a database. Mixing them up is a classic error.

Bandwidth

Bandwidth is how much data moves per second. You multiply the size of what is sent by how often it is sent.

bandwidth = requests per second x size per request

Network speeds are often quoted in bits, not bytes. One byte is 8 bits. So 100 MB per second is 800 megabits per second. If someone quotes a link in gigabits, divide by 8 to get bytes.

Do it for both directions. Data coming in (uploads) and data going out (downloads) are separate numbers. For most products, going out is far bigger.

How many servers can one machine handle

This is the part where you have to guess, and that is fine. Here are rough numbers. They are not facts of nature. They depend on what the code does. Say them as assumptions.

Then the number of servers is peak QPS divided by what one does. If you peak at 15,000 requests per second and one server does 1,000, you need about 15 servers. Add a few spare so a dead one does not hurt you. So maybe 20.

Use these as a ladder, not as a promise. The interviewer will not argue with "I will assume one app server does about 1,000 requests per second". They will argue with a number that is wildly wrong.

Worked example 1: a photo sharing app

Setup. A photo app. Assume 10 million daily users. Each user looks at 50 photos a day. One in five users uploads one photo a day. A photo is 2 MB. Everything below is rounded.

Step 1, requests per day.

• Views per day: 10 million x 50 = 500 million.
• Uploads per day: 10 million x 1/5 = 2 million.

Step 2, per second. Divide by 100,000.

• Views: 500 million / 100,000 = 5,000 per second.
• Uploads: 2 million / 100,000 = 20 per second.

Step 3, peak. Multiply by 3.

• Views peak: about 15,000 per second.
• Uploads peak: about 60 per second.

Step 4, the ratio.

• 500 million views to 2 million uploads is 250 to 1. Extremely read heavy.

Step 5, storage.

• Per day: 2 million photos x 2 MB = 4 million MB = 4 TB.
• Per year: 4 TB x 400 = 1,600 TB, which is about 1.6 PB. (The exact number with 365 would be 1.46 PB. Same ballpark.)
• The database rows are much smaller: 2 million per day x 1 KB = 2 GB per day, so about 800 GB a year. That fits on one database machine for a good while.

Step 6, bandwidth.

• Out: when you view a photo you get a smaller version, say 200 KB. 5,000 per second x 200 KB = 1,000,000 KB per second = 1 GB per second. That is 8 gigabits per second.
• In: 20 per second x 2 MB = 40 MB per second, about 320 megabits per second.

Step 7, servers.

• App servers for the API: 15,000 peak / 1,000 per server = 15. Round up to 20.
• The 1 GB per second of image traffic is not something you want your own servers to carry.

What the numbers tell you:

• Reads are 250 times writes, so put a cache in front of the metadata and use a CDN for the images. A CDN would be the first thing I draw here.
• Photos are petabytes a year, far too big for a database. They go into object storage (a service made for storing large files cheaply). The database only keeps the rows that point to them.
• Uploads are only 20 per second, which is tiny. The write path does not need anything fancy.
• One database can hold the metadata, with a few read copies, so you do not need to split it yet.

That is a complete design direction from one page of arithmetic.

Worked example 2: a chat app

Setup. A messaging app. 50 million daily users. Each user sends 40 messages a day. A message is about 100 bytes of text, round it up to 100. Assume each message is read by one other person. At any moment about 10 percent of the daily users have the app open.

Step 1, messages per day.

• 50 million x 40 = 2,000 million = 2 billion messages per day.

Step 2, per second.

• 2 billion / 100,000 = 20,000 messages per second.
• Peak, times 3: 60,000 per second.

Step 3, the ratio.

• Each message is written once and read about once. So reads and writes are close to 1 to 1. This is a write heavy system. Caches will not save you here the way they save a photo app.

Step 4, storage.

• Per day: 2 billion x 100 bytes = 200 billion bytes = 200 GB.
• Per year: 200 GB x 365 = 73,000 GB, which is about 73 TB. Call it 70 TB. (Using 400 days instead would give 80 TB. Same ballpark.)
• Five years would be about 350 TB. Too much for one machine.

Step 5, bandwidth.

• 20,000 per second x 100 bytes = 2,000,000 bytes per second = 2 MB per second.
• That is nothing. Text is tiny. Bandwidth is not a worry for this app (it would be if people send photos and video).

Step 6, connections.

• People online at once: 10 percent of 50 million = 5 million.
• Each one holds an open connection, so the server can push messages instantly.
• One server holds about 50,000 connections. 5 million / 50,000 = 100 servers.

What the numbers tell you:

• 20,000 writes a second on average, 60,000 at peak, is well above what one normal database does. The data must be split across many machines (this is called sharding, and the note on it comes later). A natural split is by chat id, so one conversation always lives together.
• 70 TB a year also points to splitting the data.
• The server count is driven by open connections (100 servers), not by request rate. That is something a beginner would miss. Request rate alone would say 60,000 / 1,000 = 60. Both numbers are the same order of magnitude, which is a nice sanity check.
• Bandwidth is tiny, so you will not spend your interview time on it.

Worked example 3: a URL shortener style service

Setup. A service that turns long links into short ones, and redirects when someone opens the short one. Assume 100 million new short links per month. Reads are 100 times writes. One stored record is about 500 bytes (the short code, the long URL, a time and a user id).

Step 1, writes per second.

• 100 million per month / 30 days = 3.3 million per day. Round to 3 million.
• 3 million / 100,000 = 30 writes per second. (If you use the month directly, 100 million / 2.5 million seconds = 40. Both answers are the same ballpark. I will use about 35.)

Step 2, reads per second.

• 100 x 35 = 3,500 reads per second.
• Peak, times 3: about 10,000 per second.

Step 3, storage.

• Per month: 100 million x 500 bytes = 50 billion bytes = 50 GB.
• Per year: 50 GB x 12 = 600 GB.
• Five years: 600 GB x 5 = 3 TB. One database machine can hold that.

Step 4, how many codes do we need?

• 100 million x 12 x 5 = 6 billion links in five years.
• If a code is made of 62 characters (a to z, A to Z, 0 to 9), then 6 characters gives 62^6, about 56 billion. 7 characters gives 62^7, about 3.5 trillion.
• 6 characters is enough but a bit tight. 7 gives lots of room.

Step 5, bandwidth.

• A redirect is tiny, about 500 bytes. 10,000 per second x 500 bytes = 5 MB per second. Nothing.

Step 6, should we cache?

• Reads per day: 3,500 x 100,000 = 350 million.
• If every read were a different link, that would be 350 million x 500 bytes = 175 GB.
• Traffic is uneven. A small share of links get most of the clicks. Say 20 percent of the links cover most of the reads. 20 percent of 175 GB is 35 GB.
• 35 GB fits in the memory of one cache machine, or a small group of them.

Step 7, servers and the database.

• 10,000 peak reads per second / 1,000 per server = 10 app servers. Round up to 15.
• If the cache catches 90 percent of reads, the database sees 10 percent of 10,000 = 1,000 reads per second. A single database handles that, with a replica or two for safety.
• Writes at 35 per second are nothing.

What the numbers tell you:

• Yes to a cache. It is cheap (35 GB) and removes 90 percent of the database load.
• No to splitting the database. 3 TB and a thousand reads a second fit on one machine with copies. Mention that you would reconsider if the numbers grew by 10 times.
• Code length: 7 characters.
• The hard part of this problem is not the size. It is making short codes that never collide. That is where your deep dive goes.

Notice how different the three answers are. A photo app needs a CDN and object storage. A chat app needs a split database and lots of connections. A shortener is small enough for one database with a cache. The estimate told you that before you drew any box.

What to do with the number

This is the step people forget, so here it is as a short list. After every estimate, say one sentence for each of these.

• Does it fit on one machine? If storage is a few TB and traffic is a few thousand a second, usually yes. Say so, and say what would make it stop fitting.
• Do I need a cache? If reads are far more than writes, and the same items get asked for again and again, yes. If it is write heavy, a cache will not help much.
• Do I need to split the database (shard)? Think about it when writes pass a few thousand a second, or storage passes a few TB. Before that, copies for reading are usually enough.
• Do I need a CDN? If you send large files (images, video) to many users, yes.
• How many app servers? Peak QPS divided by what one does, plus some spare.

And never say a number without the "so". "We have 10,000 reads a second" is a fact. "We have 10,000 reads a second, so one database is not comfortable and I want a cache" is design.

Common mistakes

Doing the math too exactly. Spending three minutes on 86,400 and 365 days. Round, say you rounded, move on.

Forgetting peak. Average traffic is not what breaks a system. The busiest hour is. Multiply the average by 2 or 3, and design for that.

Mixing bits and bytes. Network speed is in bits, storage is in bytes. A factor of 8 hides in there.

Losing a factor of 1,000. This happens when you switch between KB, MB and GB. Write the units next to every number.

Forgetting copies. Stored data is usually kept 3 times. It is fine to say so once and keep calculating without it.

Using the estimate and then ignoring it. If the answer is "one machine is enough", say that and then design for one machine with a plan to grow. Do not draw 30 boxes anyway.

Interview questions to check yourself

"About how many requests per second is 1 million requests a day?"

A day is about 100,000 seconds, so 1 million / 100,000 = about 10 per second.

"A service has 20 million daily users and each makes 10 requests a day. What is the average and peak QPS?"

20 million x 10 = 200 million a day. Divided by 100,000 that is 2,000 per second on average. Peak is 2 to 3 times that, so about 4,000 to 6,000.

"Each of 5 million items a day is 4 KB. How much storage is that in a year?"

5 million x 4 KB = 20 million KB = 20 GB per day. 20 GB x 400 = 8,000 GB, which is about 8 TB per year.

"Why do we round a day to 100,000 seconds when it is really 86,400?"

It makes the division a simple decimal shift. The error is about 15 percent, which does not change the design. The point is to get the right number of zeros.

"You calculate 50,000 writes per second. What does that tell you?"

One normal database does a few thousand writes per second, so you need to split the data across several machines (shard), or pick a store built for heavy writes. One database is not enough.