Skip to main content
logo
System design estimation · Updated November 6, 2026

Back of the envelope calculation for system design interviews

A back of the envelope calculation is a quick, rough estimate made with round numbers and simple math, good to within a factor of about 2 to 10. In a system design interview, it sizes the system: requests per second (QPS), storage and bandwidth, at average and peak. State your assumptions, divide daily volume by about 100,000 seconds, multiply by a peak factor, then multiply writes by their size and how long you keep them. The numbers tell you what the design needs, such as a cache, sharding or a CDN.

daily users × actions per user ÷ 86,400
Average QPS
average QPS × peak factor (2-3x is typical)
Peak QPS
writes per day × size × 365 × years × replicas
Storage
QPS × payload size (× 8 for bits per second)
Bandwidth
Try the estimatorLatency numbers
Free estimator

Back of the envelope calculator

Enter your assumptions, or start from one of the examples. Every result shows the formula behind it, so you can say the math out loud.

Start from an example

People who use it on a given day. Type 10M or 2.5k if you like.

Writes each user makes: posts, messages, uploads or clicks.

Reads for each write. 100 means 100 reads to 1 write.

One write, or one read response. 1 KB = 1,000 bytes here.

Peak traffic divided by average. 2 to 3 is a common start.

How long you keep what is written.

Copies of each piece of data. 3 is a common default.

In short: about 35k/s reads and 3.5k/s writes at peak, and 550 TB of storage over 5 years with 3 copies.

Traffic (QPS)

Writes per day
users × actions = 10 million × 10
100 million
Reads per day
writes × ratio = 100 million × 10
1 billion
Average write QPS
writes per day ÷ 86,400 = 100 million ÷ 86,400
1.2k/s
Peak write QPS
average × peak = 1.16k/s × 3
3.5k/s
Average read QPS
reads per day ÷ 86,400 = 1 billion ÷ 86,400
12k/s
Peak read QPS
average × peak = 11.6k/s × 3
35k/s

Storage

Per day
writes per day × size = 100 million × 1 KB
100 GB
Per year
per day × 365 = 100 GB × 365
37 TB
Before replication
per year × years = 36.5 TB × 5
180 TB
Total with replicas
before replication × copies = 183 TB × 3
550 TB

Bandwidth

In, average
write QPS × size = 1.16k/s × 1 KB, or 9.3 Mbps
1.2 MB/s
In, peak
peak write QPS × size = 3.47k/s × 1 KB, or 28 Mbps
3.5 MB/s
Out, average
read QPS × size = 11.6k/s × 1 KB, or 93 Mbps
12 MB/s
Out, peak
peak read QPS × size = 34.7k/s × 1 KB, or 280 Mbps
35 MB/s

Results are rounded to 2 significant figures, which is the right precision for an interview. Storage counts only the data you write, so add room for indexes and metadata. Bandwidth is shown in bytes per second and in bits per second, because network links are sold in bits (8 bits to a byte).

The method

How to do a back of the envelope calculation, step by step

In a 45 minute round, this is the Estimates step, and it should take about 4 minutes. It comes right after requirements; see how to answer any system design question.

  1. Step 1

    State your assumptions

    Say the daily active users, actions per user, the size of each item and the read to write ratio out loud, write them on the board, and check them with the interviewer.

  2. Step 2

    Turn daily counts into per-second rates

    Divide by 86,400 seconds, or by 100,000 for quick math. 100 million a day is about 1,200 a second.

  3. Step 3

    Apply a peak factor

    Multiply the average by 2 to 3 for a normal daily peak, and by more for launches, sales or live events.

  4. Step 4

    Split reads and writes

    Use the ratio: at 100 reads per write, 1,200 writes a second means about 120,000 reads a second.

  5. Step 5

    Estimate storage

    Multiply writes per day by the size of each write, then by 365, the years you keep the data and the number of replicas.

  6. Step 6

    Estimate bandwidth

    Multiply requests per second by the payload size for bytes per second, then by 8 for bits per second.

  7. Step 7

    Say what the numbers mean

    Turn each number into a design choice: a cache for a read-heavy load, sharding when data outgrows one machine, a CDN when egress is huge.

Cheat sheet

Handy numbers for estimates

Seconds in a day, powers of two and common data sizes: the few facts that make interview math fast.

Seconds in a day, month and year

86,400 seconds in a day. Round it to 100,000 for quick math.

Seconds per period, exact and rounded
PeriodSecondsRound to
Minute6060
Hour3,6003,600
Day86,400100,000 (10^5)
Month (30 days)2,592,0002.5 million
Year31,536,00030 million (3 × 10^7)

Per day to per second

Divide by 86,400. Learn these and you rarely need to divide at all.

Requests per day and the matching average per second
Per dayPer second
1 millionabout 12
10 millionabout 120
100 millionabout 1,200
1 billionabout 12,000
10 billionabout 120,000

Powers of two and data sizes

In estimates, 1 KB = 1,000 bytes. Binary and decimal differ by about 2% at KB and 10% at TB.

Powers of two
PowerExactRoughlySize
2^101,024about a thousand1 KB
2^201,048,576about a million1 MB
2^301,073,741,824about a billion1 GB
2^40about 1.1 trillionabout a trillion1 TB
2^50about 1.13 quadrillionabout a quadrillion1 PB

Common sizes

Add up the fields of a record, then round up for metadata.

Typical sizes of common data
ItemSize
ASCII character1 byte
Character in UTF-81 to 4 bytes
32-bit integer4 bytes
64-bit integer, timestamp or double8 bytes
UUID16 bytes (36 as text)
IPv4 or IPv6 address4 or 16 bytes
A small JSON record with a few fieldsabout 0.5 to 1 KB
A photo resized for the webabout 200 KB to 1 MB
One hour of 1080p video at 5 Mbpsabout 2.25 GB

Availability: the nines

Allowed downtime for each availability target.

Downtime allowed per year and per 30-day month
AvailabilityPer yearPer month
99%3.65 days7.2 hours
99.9%8.76 hours43 minutes
99.99%52.6 minutes4.3 minutes
99.999%5.26 minutes26 seconds

Rough capacity of one machine

Starting points to say as assumptions, not benchmarks. Real numbers depend on hardware and workload.

Rough single-machine capacity
ComponentRoughly
App serverabout 1,000 requests/s to start; far more for very light requests
Relational database primaryabout 1,000 to 10,000 writes/s; more reads with replicas and a cache
Redis or Memcached nodeabout 100,000 operations/s
Kafka brokerhundreds of MB/s
1 Gbps network link125 MB/s
Spinning diskabout 100 to 200 MB/s in sequence, about 100 to 200 random reads/s
NVMe SSDseveral GB/s in sequence, hundreds of thousands of random reads/s
Latency

Latency numbers every programmer should know

These are the commonly cited approximations from the list popularized by Jeff Dean and Peter Norvig. The figures are more than a decade old and modern hardware differs, but the gaps between memory, disk and network still teach the right lessons.

Commonly cited approximations from the list popularized by Jeff Dean and Peter Norvig. Bars use a log scale: each tenth of the track is about 10 times slower.
OperationTimeLog scaleIf an L1 hit took 1 s
L1 cache reference0.5 ns1 second
Branch mispredict5 ns10 seconds
L2 cache reference7 ns14 seconds
Mutex lock or unlock25 ns50 seconds
Main memory reference100 ns3.3 minutes
Compress 1 KB with a fast compressor (Snappy)3 µs1.7 hours
Send 1 KB over a 1 Gbps network10 µs5.6 hours
Read 4 KB at random from an SSD150 µs3.5 days
Read 1 MB in sequence from memory250 µs5.8 days
Round trip within the same data center500 µs11.6 days
Read 1 MB in sequence from an SSD1 ms23 days
Disk seek10 ms7.6 months
Read 1 MB in sequence from a spinning disk20 ms15 months
Send a packet California to the Netherlands and back150 ms9.5 years

How modern hardware differs

  • Fast NVMe SSDs read 4 KB at random in tens of microseconds and stream several GB a second, so the SSD rows are several times faster today.
  • Data center networks commonly run at 10 to 100 Gbps, so sending 1 KB takes far less than 10 µs.
  • Memory bandwidth is higher too: reading 1 MB from memory takes tens of microseconds, not 250.
  • Cache and main memory latency have changed little: an L1 hit is still about a nanosecond and main memory about 100 ns.
  • Spinning disks still seek in milliseconds, and a packet from California to Europe and back still takes 100 ms or more, because of the speed of light in fiber.

What the ratios teach

  • A memory read is more than 1,000 times faster than a random SSD read, so a cache in memory pays off.
  • A round trip inside a data center costs about 5,000 memory reads, so batch calls and avoid chatty services.
  • A cross-continent round trip is about 300 times a data center round trip, so serve users from a nearby region or a CDN.
  • Reading in sequence beats random reads by a wide margin on every kind of storage, which is why logs and append-only designs are fast.
Worked examples

Back of the envelope estimation: 4 worked examples

Four classic system design questions, sized the way you would do it at the whiteboard. Each links to the full answer.

URL shortener

Assumptions

  • 100M new links a day
  • 100 redirects per link (100:1)
  • 500 bytes per link
  • Keep 5 years, 3 replicas, 2x peak

The math

Writes
100M ÷ 86,400 ≈ 1.2k/s, peak ≈ 2.3k/s
Reads
1.2k × 100 ≈ 120k/s, peak ≈ 230k/s
Storage
100M × 500 B = 50 GB/day → 18 TB/year → 91 TB in 5 years → 270 TB with 3 replicas
Bandwidth out
116k/s × 500 B ≈ 58 MB/s (460 Mbps), about 120 MB/s at peak
Code length
100M × 365 × 5 ≈ 183B links; 62^7 ≈ 3.5 trillion, so 7 characters
Hot cache
20M hot links × 500 B = 10 GB, fits in memory

What it means for the design

Reads are 100 times writes, so the read path gets a cache in front of a key-value store. 270 TB means the store is sharded by code. 1.2k writes a second is modest; the ID scheme matters more than write throughput.

Full answer: URL shortener

Chat app

Assumptions

  • 100M daily users, 50 messages each
  • 100 bytes per message, mostly 1:1
  • 10% online at peak, 100k connections per server
  • Keep 5 years, 3 replicas, 3.5x peak

The math

Messages
100M × 50 = 5B/day ÷ 86,400 ≈ 58k/s, peak ≈ 200k/s
Connections
10% × 100M = 10M; 10M ÷ 100k ≈ 100 gateway servers
Storage
5B × 100 B = 500 GB/day → 180 TB/year → 910 TB in 5 years → 2.7 PB with replicas
Bandwidth
200k/s × 100 B = 20 MB/s (160 Mbps) in at peak, about the same out

What it means for the design

Bandwidth is small, but the message rate and the connection count are large: the gateway fleet is sized by connections. Storage grows into petabytes, so partition messages by conversation and move old history to cheaper storage.

Full answer: Chat app

Video upload and streaming

Assumptions

  • 500 hours uploaded a minute
  • Source at about 5 Mbps (2.25 GB an hour)
  • All renditions about 11 Mbps (about 5 GB an hour)
  • 100M viewers at peak at 5 Mbps; one CPU core encodes one rendition in real time

The math

Uploads
500 h × 60 × 24 = 720k hours/day
Ingest
720k × 2.25 GB ≈ 1.6 PB/day ÷ 86,400 ≈ 19 GB/s (150 Gbps)
Storage
720k × 5 GB = 3.6 PB/day ≈ 1.3 EB/year, before replication
Egress
100M × 5 Mbps = 500 Tbps, over 3,000 times the ingest
Transcoding
720k h × 5 renditions = 3.6M core-hours/day ÷ 24 ≈ 150k cores busy all day

What it means for the design

Egress settles the design: no data center serves 500 Tbps, so playback has to come from CDN edges. Storage of more than an exabyte a year calls for cheaper tiers and erasure coding for cold videos, and transcoding is its own large, parallel batch system.

Full answer: Video upload and streaming

Ad click aggregator

Assumptions

  • 10B clicks a day, 200 bytes each
  • 4-5x peak, 1-minute windows, 5 minutes of allowed lateness
  • 1M ads clicked in a busy minute, 40 bytes per count row
  • Raw clicks kept 1 year, 3 replicas

The math

Clicks
10B ÷ 86,400 ≈ 116k/s, peak ≈ 500k/s
Ingest
500k/s × 200 B = 100 MB/s (800 Mbps) at peak
Raw storage
10B × 200 B = 2 TB/day → 730 TB/year → 2.2 PB with replicas
Aggregates
1M rows/min × 1,440 = 1.4B rows/day × 40 B ≈ 58 GB/day
Dedupe state
500k/s × 600 s = 300M click ids × 16 B ≈ 4.8 GB

What it means for the design

The stream itself is modest for a partitioned log and a stream processor, and dedupe state fits in memory across the job. The aggregate store takes about 17k upserts a second (1M a minute). The raw log is the big storage cost, so tier it to cold storage after a few weeks.

Full answer: Ad click aggregator
In the room

Rounding tips, common mistakes and what interviewers listen for

Rounding tips

  • Round 86,400 to 100,000. Per-second numbers come out about 14% low, so round the answer up a little.
  • Work in powers of ten: 10^8 a day ÷ 10^5 seconds = 10^3 a second.
  • Keep one or two significant figures: 1,157 becomes 1.2k.
  • Round demand up and capacity down, so errors land on the safe side.
  • Use 2.5 million seconds in a month and 30 million in a year.
  • Treat 2^10 as 1,000. The gap is 2% at KB and about 10% at TB.
  • Write the unit at every step, and watch bits (network) versus bytes (storage).

Common mistakes

  • Spending 10 minutes on arithmetic. Aim for about 4 minutes in a 45 minute round.
  • False precision: "1,157.4 QPS" wastes time and signals nothing.
  • Forgetting the peak. The average hides the load you must survive.
  • Forgetting replicas, indexes and metadata, which can triple raw storage or more.
  • Mixing up bits and bytes (8x) or per day and per second (86,400x).
  • Estimating things that do not change the design.
  • Doing the math silently, so the interviewer cannot correct an assumption early.

What interviewers listen for

  • Assumptions stated first and checked: "Can I assume 100 million daily users?"
  • Quick, clean math with round numbers, written on the board.
  • A conclusion for every number: "so we need a cache", "so one primary can take the writes", "so this has to be sharded".
  • A sanity check: "500 Tbps is far beyond one data center, so this is a CDN problem."
  • Redoing the estimate calmly when the interviewer changes a requirement.
Practice

Practice estimates in a real round

Knowing the formulas is half of it. The other half is doing them out loud, fast, while someone asks follow-ups.

Live Copilot

The number to mention, on the call

In a live system design round, OphyAI Live Copilot shows "The number to mention" for each question: the one estimate that backs up your answer, such as requests per second or storage, with a short note on where it comes from. It sits next to a short answer to say and what to draw next.

See System Design
Mock round · 20 credits

Estimates scored as a skill

In a mock round, a voice AI interviewer asks follow-ups about what you put on the whiteboard. The Scorecard rates 7 skills, Estimates among them, and shows your time on each step against a target. The Scorecard is an AI estimate. System Design is on the Premium plan ($59 a month).

Start a mock round

Back of the envelope calculation: FAQ

What is a back of the envelope calculation?

A back of the envelope calculation is a quick, rough estimate made with round numbers and simple math, the kind you could do on the back of an envelope. It aims to be right within a factor of about 2 to 10, not exact. In a system design interview, it sizes the system: requests per second, storage and bandwidth, at average and peak load.

How do you do a back of the envelope calculation in a system design interview?

State your assumptions (daily active users, actions per user, data sizes, read to write ratio) and check them with the interviewer. Divide daily counts by about 100,000 seconds to get requests per second, and multiply by a peak factor of 2 to 3. For storage, multiply writes per day by the size of each write, then by 365, the years you keep data and the number of replicas. For bandwidth, multiply requests per second by the payload size. Then say what the numbers mean for the design. The whole step should take about 4 minutes.

How do you calculate QPS from daily active users?

Multiply daily active users by the actions each one takes per day, then divide by 86,400 seconds. For example, 10 million users making 10 requests a day is 100 million requests, and 100 million divided by 86,400 is about 1,160 requests per second on average. Multiply by a peak factor, such as 3, to get the peak: about 3,500 per second.

How many seconds are in a day, and why round to 100,000?

There are 86,400 seconds in a day (24 × 60 × 60). Rounding to 100,000 makes the math easy: divide by 10 to the 5th power. It makes per-second numbers about 14% low, so round your answer up a little, or remember a few exact pairs: 1 million a day is about 12 a second, and 1 billion a day is about 11,600 a second.

What are the latency numbers every programmer should know?

They are a list of rough costs for common operations, popularized by Jeff Dean and Peter Norvig. The commonly cited values: L1 cache reference 0.5 ns, main memory reference 100 ns, sending 1 KB over a 1 Gbps network 10 µs, reading 4 KB at random from an SSD 150 µs, a round trip within a data center 500 µs, a disk seek 10 ms, and a packet from California to the Netherlands and back 150 ms. Modern hardware is faster in places, especially SSDs and networks, but the gaps between memory, disk and network are still huge.

How precise should my estimates be?

One or two significant figures is enough. Say "about 1,200 requests a second", not "1,157.4". Interviewers care that your numbers are the right order of magnitude and that you use them to make design choices, such as adding a cache or sharding a database.

What peak factor should I use?

For most consumer apps, a peak of 2 to 3 times the daily average is a fair starting point. Use more for spiky traffic: a flash sale, a ticket on-sale, a live event or a marketing blast can run 10 times average or far more. Say the number you picked and why.

Do I need to memorize powers of two?

Just the main ones: 2 to the 10th is about a thousand (KB), 2 to the 20th about a million (MB), 2 to the 30th about a billion (GB) and 2 to the 40th about a trillion (TB). In estimates, treat 1 KB as 1,000 bytes. The gap between binary and decimal units is about 2% at KB and about 10% at TB, which rarely changes a design.

Related

Keep going

System design interview questions18 classic questions, each with requirements, estimates, a diagram and deep dives.OphyAI System DesignMock rounds with a voice AI interviewer, and Live Copilot for the real round.System design interview guideThe six steps of the round, from requirements to wrap up.

Size the system out loud, then design it

Practice the estimates step inside a full system design mock round, with a voice AI interviewer and a Scorecard.

Practice a mock roundSee the 18 questions