System Design: Back-of-the-Envelope Estimation

How to read it: the top row finds load, the last arrow turns load into machines, and the branch at the bottom turns the same request count into bytes.

• DAU is daily active users, usually much smaller than total registered users.
• Peak factor is how much busier the busiest moment is than the average. A factor of 2 to 5 is a common starting assumption for consumer apps; without data pick 3 and say so.
• Read/write ratio is how many reads happen per write. It often decides whether you invest in caches and replicas (many reads) or write scaling (many writes).

A worked example: the photo-sharing app

Everything below is an illustrative assumption. A real product would replace these with measurements.

Assumptions: 10 million registered users and 2 million DAU; each DAU views 30 photos and uploads 0.1 photos a day; an original is about 2 MB and the resized versions add about 0.5 MB (2.5 MB stored per photo); a view delivers a medium image of about 200 KB; peak factor 3; metadata is about 1 KB per photo.

Requests. Reads: 2,000,000 x 30 = 60,000,000 views a day, about 700 per second on average and about 2,100 reads per second at peak. Writes: 2,000,000 x 0.1 = 200,000 uploads a day, about 2.3 per second and about 7 per second at peak. The ratio is 60,000,000 / 200,000 = 300 to 1: upload is not the scaling problem, viewing is.

Storage. 200,000 photos x 2.5 MB = 500,000 MB, so about 500 GB per day and roughly 180 TB per year (500 GB x 365 is about 182,000 GB). That belongs in object storage, not a relational database. Metadata is 200,000 x 1 KB = 200 MB a day, about 73 GB a year. Two datasets more than a thousand times different in size belong in different kinds of storage, and estimation found that in two lines.

Bandwidth. Egress is 60,000,000 x 200 KB = 12 TB a day, about 140 MB per second, or about 1.1 Gbps on average (140 x 8 = 1,120 Mbps) and about 3.3 Gbps at peak. Serving that from your own servers is expensive, so a CDN absorbs it. If we assume it serves 90% from edge caches, about 10% reaches your origin: roughly 0.33 Gbps at peak. Ingress is 200,000 x 2 MB = 400 GB a day, modest at about 37 Mbps on average.

Cache memory. Cache each active user's feed as 100 photo IDs of 8 bytes: 800 bytes x 2,000,000 = 1.6 GB. Add a hot set of 1 million metadata records at 1 KB (1 GB) for about 2.6 GB. Double it for key and structure overhead and you get about 5 GB, which fits one modest node, though we would run two for availability.

Servers and database. If one application instance handles about 500 simple requests per second (assumed), 2,100 peak needs 4 to 5 instances, so run perhaps 8 for headroom. If the cache absorbs 90% of metadata reads, the database sees about 210 reads per second and 7 writes. One well-indexed relational database copes, so the estimate says skip sharding for now.

Spiky traffic: which number do you size for?

The photo app has a gentle daily curve, so a peak factor of 3 is reasonable. Event-driven products do not. A concert on-sale can send more than a hundred times the normal traffic in the first minutes. This flowchart picks the number to design for.

How to read it: if you can control how fast work enters the expensive part of the system, size that part for the rate you choose, and separately size the cheap front door that absorbs the rush.

Sanity checks and rounding

• Compare against a known reference. If you estimate that one server does 1,000,000 database-backed requests per second, your intuition should object. A single machine often handles hundreds to a few thousand, depending heavily on the work.
• Check units. Bits versus bytes, per second versus per day, KB versus MB. Most big errors are unit mistakes.
• Estimate it two ways. Compute bandwidth from requests and sizes, then from storage turnover. If they differ by 100 times, an assumption is wrong.
• Round to one significant digit and state the range. "Between 1,500 and 3,000 per second" is more honest than "2,083.3".

In practice: a ticketing platform prepares for a concert on-sale

The situation

A ticketing platform with an eight-person engineering team will put 40,000 tickets for a major concert on sale at 10:00 on a Saturday. The stack runs on Kubernetes: six API pods, PostgreSQL with one read replica, Redis, and a third-party payment gateway. Normal traffic is about 300 requests per second (assumed). The last big on-sale ended with a 40-minute outage and an apology.

Marketing expects 250,000 fans online at 10:00. Assume they arrive within five minutes, so about 833 arrivals per second. Every browser sits on the page and polls "any tickets yet?" every 5 seconds: 250,000 / 5 = 50,000 requests per second, roughly 167 times the normal 300. Meanwhile at most 40,000 tickets, about 2 per order, means around 20,000 orders at best, over perhaps ten minutes, a few dozen orders per second. The polling traffic outnumbers purchases by more than a thousand to one.

Starting architecture

How to read it: every request, including the useless polls, reaches the same API pods and the same database. If one pod handles about 200 simple requests per second (assumed), six pods give 1,200. Meeting 50,000 by brute force means roughly 250 pods.

Options considered

The decision

The numbers behind the decision: with a 15-second poll, 250,000 / 15 is about 16,700 status requests per second. Assume the status service does about 5,000 per second per instance (it is one Redis read): four instances, eight for headroom. Admitting 60 fans per second moves 40,000 fans through in about 667 seconds, roughly 11 minutes, and if half of them buy that covers the 20,000 orders. If each admitted fan spends about 5 minutes in checkout, concurrent shoppers are 60 x 300 = 18,000 (arrival rate times time in system). At about 25 requests per checkout, that is 60 x 25 = 1,500 requests per second on the real API. At 200 per pod that is about eight pods, so scale the API tier up for the day. Most of those requests are cheap reads, so the database sees far fewer queries than the API sees requests, though the seat-hold writes still need a load test.

Rollout and verification

Ship it for a smaller, lower-demand event first. Before the big day, load-test staging with production-sized data (a tool such as k6 can ramp virtual users) to at least 60,000 status requests per second and 100 admissions per second, which is above the plan. Dashboards in Grafana: arrivals per second, queue depth, admissions per second, status-service p99 latency and 5xx rate, Redis CPU, database transactions per second, payment error rate and CDN offload. The target, not a promise: status p99 under 300 ms, checkout p95 under 800 ms at 60 admissions per second.

The 2 a.m. failure

A show in another time zone goes on sale at 02:00 for the team. At 02:03 the page reads "status service 5xx above 20%". The Redis primary failed over, a few seconds of errors followed, and the clients retried instantly, with no backoff, doubling the incoming load.

First three checks: the status 5xx and latency panel, redis-cli INFO replication (the role and master_link_status), and kubectl get hpa and kubectl top pods for the status service. Mitigation: raise the server-sent poll interval through a flag, return 429 with Retry-After at the CDN edge for clients that poll too often, and pause admission until Redis is stable. Follow-up: ship client-side exponential backoff with jitter, serve the last known queue state from a short in-process cache for a few seconds, and rehearse a Redis failover in a game day.

Architect's notes

• Estimate the burst, not the day. The daily average hides the minutes that cause outages. Ask for arrivals per second at the opening minute.
• Find the expensive resource and protect it. Here it is the order path in PostgreSQL. Everything else exists to shield it.
• Count polling. Clients that poll multiply load by users divided by interval. Longer, server-controlled, jittered intervals are the cheapest scaling lever.
• Ask in the review: what is the plan when the estimate is 3 times too low? Pre-agree the lever (slow admissions, shed load) before the day.
• Defer permanent capacity. Rent extra pods for the on-sale and scale down afterwards. Do not buy for a peak that happens a few times a year.

Common mistakes

• Chasing precision. An hour on exact numbers when the decision needs the order of magnitude. Fix: round to one significant digit.
• Hidden assumptions. Inputs nobody wrote down cannot be challenged. Fix: list every assumption next to the result.
• Averaging instead of peaking. Systems fail at the peak, so always apply a peak factor, and for events size for the burst.
• Confusing registered with daily active users. That can inflate load ten times. Fix: ask which one the number is.
• Skipping the sanity check. A unit slip, such as bits versus bytes (a factor of eight), makes a result wrong by a lot. Fix: recheck units against a known reference.
• Estimating only requests. Storage, bandwidth and memory often shape the design more. Fix: estimate all four, and remember replication multiplies storage cost.
• Treating all requests as equal. A search or an image resize costs far more than a cached read. Fix: weight by cost and plan growth headroom.

Key takeaways

• Order of magnitude is the goal. Tens, thousands or millions, not the exact figure.
• Chain from users to resources. Users, actions, requests per second, then storage, bandwidth, memory and machines.
• Learn a few constants. A day is about 10^5 seconds, and a million requests per day is about 12 per second.
• Know the latency ladder. Memory, SSD, same-data-centre network and cross-ocean network differ by large factors.
• Always apply a peak factor. For event-driven traffic, size for the burst and consider smoothing it.
• Read/write ratio steers design. A 300-to-1 read-heavy workload points to caches, replicas and a CDN.
• Estimates can say no. Good numbers tell you what you do not need yet, such as sharding.
• Label and recheck. Mark every input as an assumption, check units, and refine when real data arrives.

Practice exercises

Exercise 1 — Starter (30 min): A messaging app has 5 million daily active users who each send 40 messages per day. Calculate average and peak messages per second (peak factor 3). Then, assuming each message is 200 bytes, calculate how much message data is created per day and per year.

Exercise 2 — Intermediate (2 hours): Redo the photo-app estimate with 20 million DAU, each viewing 50 photos and uploading 0.2 photos a day, original size 3 MB. Produce a new summary table, then write two sentences on which conclusions changed (for example, does one relational database still suffice for metadata reads behind a cache?) and which stayed the same.

Exercise 3 — Advanced (half day): Estimate a URL shortener with 100 million new links per month and a 100-to-1 read-to-write ratio. Calculate writes and reads per second at average and peak, storage over five years assuming 500 bytes per record, and the cache size needed if 20% of links get 80% of the traffic. Write down every assumption, then identify the single input that most changes your answer and explain how you would measure it for real.

Related reading

• Requirements and Scope - where the scale assumptions used here come from.
• The Request Lifecycle - the next lesson, showing where each of those milliseconds goes.
• Caching Basics - how to put the cache size and hit-ratio estimates to work.
• CDN and Object Storage - the components the bandwidth and storage numbers point to.
• Capacity and Cost - the advanced version: turning estimates into a capacity plan.