Back-of-Envelope Estimation

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Turn people per day into requests per second, storage, bandwidth and servers with quick, rounded sums, and learn why you always plan for the peak.

Imagine you are planning food for a wedding.

You would not count every grain of rice. Instead, you would ask a few simple questions. How many guests will attend? How much does each person usually eat? When will most people eat at the same time? With a few rough numbers, you can quickly estimate whether you need one cook or ten.

Engineers use the same approach when designing systems. It is called back-of-envelope estimation. These are quick calculations using rounded numbers, simple enough to fit on the back of an envelope.

The main idea: you do not need perfectly accurate numbers. You need estimates that are close enough to help you choose the right design.

What You Will Learn

In this lesson, you will learn:

1. Why rough estimates are usually enough.
2. A few useful numbers to remember.
3. How to convert daily users into requests per second.
4. Why systems should be designed for peak traffic, not average traffic.
5. How to estimate storage requirements.
6. How to estimate bandwidth requirements.
7. How to estimate the number of servers needed.
8. How to document assumptions and verify your estimates.

Why Rough Numbers Are Enough

The purpose of estimation is to answer one question:

What size of system do we need?

• 10 requests per second? One small server is probably enough.
• 10,000 requests per second? You will need multiple servers and a way to distribute the workload.

The difference between those numbers is huge. Being 20% off usually does not change the design. Being 10 times off probably does.

The goal is to be roughly correct as quickly as possible. Exact calculations take longer and are often based on assumptions anyway.

In simple terms: being close enough is usually good enough, as long as you are in the correct range.

Handy Numbers to Remember

Seconds in a Day

There are 86,400 seconds in a day. For quick calculations, many engineers round this to 100,000.

Here is 1 million orders a day, worked out both ways:

The rounded value is 10. The exact value is 11.6. Both lead to the same design decision.

Storage Units

Storage units increase in steps of approximately 1,000.

For this course:

• 1 KB = 1,000 bytes
• 1 MB = 1,000 KB
• 1 GB = 1,000 MB
• 1 TB = 1,000 GB

Computers sometimes use 1,024 instead, but for estimation the difference is usually not important.

A Short Cheat Sheet

Step 1: Requests per Second

The most important estimate is often requests per second (QPS).

From People to Requests

Start with users and work through four simple steps.

1. Start with Daily Active Users (DAU).
2. Multiply by the number of actions each user performs per day.
3. Divide by the number of seconds in a day.
4. Multiply by the peak factor.

For QuickBite, step through the four steps:

Peak, Not Average

Users do not use QuickBite evenly throughout the day.

Almost nobody orders food at 4 a.m., while large numbers of users place orders during lunch and dinner.

The peak factor describes how much busier the busiest period is compared to the average period.

For food delivery systems, a peak factor between 3 and 5 is a reasonable starting assumption.

Your system must handle peak traffic. If it can only handle average traffic, it will fail during lunch and dinner when demand is highest.

The wrong way first: plan for the average

Say one server handles 500 requests a second. Watch what happens if you buy servers for the average:

Planning for the average gives 1 server. It handles 500 a second, but lunch needs 1,157. That leaves 657 requests a second with nowhere to go.

A design that appears fine on paper can fail completely during peak traffic.

Reads and Writes

Consider QuickBite's main activities:

• Reads: viewing restaurant menus, about 20 million times per day.
• Writes: placing orders, about 1 million times per day.

This gives approximately 20 reads for every write.

Such a system is called read-heavy.

This ratio strongly influences future design decisions. Read-heavy systems benefit significantly from caching because the same data is requested repeatedly.

Step 2: Storage

Storage estimation answers one question:

How much space will the stored data require?

The process is simple:

1. How many records are created each day?
2. How large is each record?
3. How long is the data kept?
4. How many copies are stored?

Most production systems keep multiple copies of data for durability.

Step through QuickBite's orders:

That is 2 GB per day, and 2,190 GB per year with 3 copies (about 2.2 TB).

At roughly 2.2 TB per year, order records are not a major storage challenge.

Restaurant photos are a different story because images are much larger than text records.

Step 3: Bandwidth

Bandwidth measures how much data moves through the network each second.

Think of it as the width of a water pipe.

Calculate it by multiplying requests per second by response size. The chart follows QuickBite's menu pages at lunch:

Network speeds are usually measured in bits, while file sizes are usually measured in bytes. Since one byte equals eight bits, conversion requires multiplying by eight.

Step 4: Servers

Leave Spare Capacity

A server running at 100% utilization has no room for unexpected traffic spikes.

A common approach is to keep approximately 30% spare capacity and use only about 70% of the server's maximum capability.

At lunch QuickBite needs 1,157 menu views + 58 orders = 1,215 requests a second. The chart shows how that becomes 4 servers instead of 3:

The value "500 requests per second per server" is itself an assumption. In production, engineers validate such numbers through load testing.

Write Down Your Assumptions

Every estimate depends on assumptions.

Record them clearly.

If any assumption changes, you only need to update that value and recalculate.

Check Whether the Answer Makes Sense

After every estimate, perform a sanity check.

Ask:

Does this result seem reasonable?

Examples:

• 4 servers for 2 million daily users? Reasonable.
• 4,000 servers for 2 million daily users? Probably incorrect.
• 2 petabytes of order data each year? Probably a unit conversion mistake.

A quick review often catches major errors before they influence the design.

Try It: The Estimator

Adjust the sliders and observe how each estimate changes.

Notice that when users increase by 10×, requests, storage, and bandwidth also increase by roughly 10×.

Server counts increase in steps because servers can only be added as whole units.

Try It: Estimate Challenge

Solve the estimation yourself using rounded numbers.

Any answer within approximately 20% of the reference solution is considered acceptable.

Common Mistakes

Practice

What to Remember

• Estimates only need to be roughly correct.
• There are 86,400 seconds in a day. Rounding to 100,000 is often sufficient.
• People × Actions ÷ Seconds = Average Requests Per Second.
• Multiply by the Peak Factor to estimate busiest-time traffic.
• Storage = Records × Size × Time × Copies.
• Bandwidth = Requests Per Second × Response Size.
• Leave roughly 30% spare capacity on servers.
• Document assumptions, label units, and verify results using common sense.

Further Reading

These are the sources this lesson was checked against:

• ByteByteGo: Back-of-the-Envelope Estimation: handy numbers, the QPS and storage method, and tips on rounding and units.
• Hello Interview: Requirements Gathering: ask for user counts, then work out per-second rates yourself.
• System Design Primer: a free overview that includes back-of-envelope tables.

Next: Latency and the Request Path, where you will follow a QuickBite request from the mobile phone to the database and back, learning where time is spent along the way.