What are Back-of-the-Envelope Estimations?

Two of these matter most.

A day is about 100,000 seconds. It is really 86,400, and rounding up to 100,000 makes every division you do afterwards simple enough to do mentally. The error is fourteen percent, which is too small to matter compared with assumptions you have already rounded much harder.

One million a day is about twelve per second. Once you have this, most load questions become simple multiplication. A billion a day is twelve thousand per second. A hundred million is about twelve hundred.

Four Moves

The method is four things, done out loud.

Round, early and hard. Turn 86,400 into 100,000 and 1,024 into 1,000 before you start, not after. The point is not laziness. Rounding first keeps the arithmetic simple enough that you will not make a mistake while talking, and a mistake costs you far more than the lost precision does.

Break the problem into parts. Do not guess total storage. Estimate photos, then metadata, then user records, then add them up. Each piece is a number you can justify, and when one is wrong you can fix that piece rather than starting over.

Work in powers of ten. Track the magnitude separately from the digits. "Two times ten to the ninth" is easier to follow through four steps of arithmetic than "2,000,000,000", and it makes the final unit obvious.

Sanity check the answer. Ask whether the result is believable before you build on it. If one year of profile text comes to 40 petabytes, you have made a mistake, and finding it now is much cheaper than designing storage tiers on top of it.

Deriving the Rest

Almost every estimate in an interview comes from the same sequence of steps. You agree a user count, and everything else follows.

Notice the split at the bottom, because it is where most mistakes happen. Storage comes from totals. Bandwidth comes from concurrency.

Load

A social platform has 100 million daily active users posting 10 times a day.

100M users x 10 posts        = 1B posts per day
1B / 100,000 seconds         = ~10,000 writes per second, average

Average is not what you design for. Traffic peaks, and a factor of two to three is a reasonable default to state:

10,000 x 3                   = ~30,000 writes per second at peak

Then ask for the read-to-write ratio, because it is the most useful number in the whole exercise. At a hundred reads per write you get three million reads per second, and that single figure is what justifies caching, replicas and a CDN for the rest of the interview.

Storage

A photo app has 500 million users uploading 2 photos a day at 2 MB each.

500M x 2 x 2 MB              = 2 PB per day
2 PB x 365                   = ~730 PB per year

Then adjust for what you actually keep. Three replicas triples it. Thumbnails add ten to twenty percent. Compression may reduce it somewhat. The first number is the one that matters, because 2 PB a day already tells you this is object storage and never a database.

Bandwidth

A video service has 10 million daily users watching about an hour each, at 4 Mbps for 1080p.

The common mistake is multiplying 10 million by 4 Mbps. That gives 40 Tbps and assumes everybody watches at the same instant, which never happens. Find the concurrency first:

10M users x 1 hour           = 10M viewing-hours per day
10M / 24 hours               = ~420K watching at any moment
420K x 3 (peak)              = ~1.25M concurrent viewers
1.25M x 4 Mbps               = ~5 Tbps at peak

Still enormous, and that is the point. The number tells you immediately that serving this from your own origin is not an option and that a CDN is doing nearly all the work.

Latency: Ratios, Not Values

There is a well known table of latency numbers, and the usual advice is to memorise it. That is the wrong lesson. Nobody will ask you what an L1 cache reference costs, and knowing it changes no design.

What changes designs is the gap between the levels.

Three ratios are worth remembering:

• Memory is about a hundred thousand times faster than a disk seek. This is why caching exists and why it is usually the single change with the largest effect.
• An SSD read is roughly a hundred times faster than a spinning disk seek. This is why storage engine choice matters at high read volume.
• Crossing an ocean costs somewhere near 100 ms, and no engineering removes it. This is why multi-region designs place data near users instead of trying to remove the delay with complex engineering.

If you can say "that read goes to disk, so it is milliseconds, not microseconds, which is why I am putting a cache in front of it", you have used the table correctly and you never had to recall a single figure from it.

When You Do Not Know a Number

You often will not, and interviewers frequently leave it vague on purpose to see what you do.

The wrong moves are guessing silently and stalling. The right move is one sentence: state the assumption out loud and invite correction.

"You have not given me a number, so I will assume 100 million daily users and about 500,000 reads per second at peak. Tell me if that is wrong."

Now you have something to design against, the interviewer has a chance to redirect you, and if your assumption is wrong by ten times you will usually find that the design barely changes. When it would change, say that too: "at ten times this, the data no longer fits on one machine and I would shard."

💡 In the interview: keep the whole thing to three or four minutes and say the numbers out loud as you go. Two habits give most of the benefit. Round before you calculate, not after, because arithmetic done while talking is where mistakes happen. And finish every estimate with the design decision it implies: not "so that is about 2 petabytes a year", but "so that is about 2 petabytes a year, which means object storage and a CDN, and the metadata database only ever holds paths." An estimate that does not change a decision was not worth the time you spent on it.

Key takeaway: back-of-the-envelope estimation is about order of magnitude, because that is what changes a design. Remember a few anchor numbers, above all that a day is roughly 100,000 seconds and that a million a day is about twelve per second. Round hard first, break the problem into parts, work in powers of ten, and sanity check the result. Derive load from users and actions, storage from totals, and bandwidth from concurrent users rather than total ones. Treat latency figures as ratios rather than values, and when a number is missing, assume out loud and let the interviewer correct you.