Lesson 02 — Workload Estimation · Staff+ System Design

Staff+ skill · make numbers earn their place in the design

🎧 Listen to this lesson · narrated audiobook edition

⏱ ~13 min read · 🎧 ~5 min listen · ✎ 10 quizzes · 🧮 ~30 min exercise

An estimate is not a prediction with a confident voice. It is a small model: inputs, arithmetic, and a range that someone else can challenge. In Lesson 01 you scoped Encore, the fictional event discovery and ticket-booking service. Now you will turn a workload brief into rates, retained data, and transfer volumes before choosing components.¹

Name the quantity before dividing

Start with requests per day, not “users.” Divide a daily request total by 86,400 to get an average requests-per-second rate. Keep reads and writes separate. A daily average is a useful baseline, but it can hide a sharp event-sale burst, so state a peak factor and the interval it represents. The factor comes from the exercise facts or a labeled assumption; it is not a universal constant.

Question	Quick model	What to say aloud
Average rate	daily requests ÷ 86,400	“About X reads and Y bookings each second on an average day.”
Peak rate	average rate × stated peak factor	“During a major on-sale, I’ll use this factor for this time window.”
Read/write mix	daily reads ÷ daily writes	“This is roughly R reads for every W write; here’s what I counted.”
Retained data	records/day × bytes/record × retention	“This is raw logical data; indexes and replicas are outside this first pass.”
Transfer rate	requests/second × average payload bytes	“I’m estimating outbound reads separately from inbound booking requests.”

Average is not peak Dividing a daily total by seconds gives a useful baseline, not a capacity plan. A ticket sale can be quiet for hours and busy for minutes; keep the burst and its duration visible.

Estimate in a useful order

Write the input beside every result. First estimate average read and write rates. Then apply the exercise’s peak assumptions to each flow; reads and bookings may peak differently. Next estimate raw retained booking data. Finally estimate network transfer from request rates and average payload sizes. Use consistent decimal or binary units, round to a useful magnitude, and say what is excluded.²

A range is more honest than false precision. If the payload could plausibly double, calculate both ends. Then ask whether the range changes a design choice. If both ends fit the same option, the uncertainty may not matter yet. If one end crosses a limit or changes cost substantially, call that out as a sensitivity to measure. The goal is not to guess perfectly; it is to identify which unknown could move the architecture.³

Keep bytes and bits straight Storage is usually discussed in bytes; network rates are often discussed in bits per second. State the unit, the direction, and the payload. Multiplying bytes per second by eight converts the rate to bits per second.

The mental model Estimate the workload you actually scoped, separate ordinary demand from bursts, and let the range expose which assumptions deserve better evidence.

🧮 Exercise: extend the Encore brief

Continue the Week 1 artifact from Lesson 01. The inputs below are fictional exercise facts, not claims about real ticketing services. Each count refers to a logical service request unless it explicitly says successful booking.

Fictional input	Value
Event listing and search read requests on a typical day	1,200,000 per day
Successful booking writes on a typical day	48,000 per day
Major event on-sale read peak	12× the average read rate for about 15 minutes
Major event on-sale booking peak	20× the average booking rate for about 10 minutes
Average retained booking record	4,000 bytes; retain for 3 years (use 365 days/year)
Average event-search response / booking request body	24,000 bytes outbound / 2,000 bytes inbound
AI event recommendations	Not approved for launch; exclude recommendation/model requests from these totals

Calculate average read and booking requests per second: divide each daily total by 86,400.
Apply the separate peak factors. Keep the read peak and booking peak distinct, and label the time window.
Calculate the daily read-to-booking ratio. State exactly what is in the numerator and denominator.
Estimate three years of raw booking records. Use decimal GB and exclude indexes, replicas, and backups.
Estimate average and peak read-response bandwidth, then average and peak inbound booking-request bandwidth. Convert bytes per second to bits per second.
Write a plausible range for one input and identify a later design decision that range could change.

Your rough check should land near 14 average reads/second, 0.56 bookings/second, 167 peak reads/second, and 11 peak bookings/second. The daily read-to-booking ratio is 25:1. Three years of raw booking records are about 210 decimal GB. At 24,000 bytes per response, average read transfer is about 2.7 megabits/second and the stated read peak about 32 megabits/second. Booking-request ingress is much smaller. Rounding is fine; keep the assumptions and units attached.

For a five-minute estimation drill, set your timer and narrate the estimate before looking at the rough check. Tell the interviewer which inputs are supplied, which you are assuming, what the units are, and what the estimate might change. Then say “Time is up.” A chat model cannot enforce the clock, so use your own timer.

🤖 Practice with an AI interviewer

Copy into any AI chat and run a five-minute timer. Estimate aloud or in writing; the interviewer should challenge your inputs, not do the arithmetic for you.

Act as a realistic Staff-level system design interviewer. We are practicing only workload estimation for the fictional Encore event discovery and ticket-booking service. Do not design components with me.

Stay in character and ask one question at a time. Do not show the fact sheet or give me the calculations unless I ask for a specific input. Ask me to state units and assumptions. Challenge a missing peak, mixed read/write count, unclear retention, false precision, or a calculation without a design implication. Do not coach me during the drill or invent extra facts. If a fact is not supplied below, say it is unknown and ask me to choose and label an assumption.

Interviewer fact sheet — reveal only the fact I ask for:
- 1,200,000 event listing/search read requests on a typical day.
- 48,000 successful booking writes on a typical day.
- The read peak during a major event on-sale is 12 times average for about 15 minutes.
- The booking peak is 20 times average for about 10 minutes.
- One retained booking record averages 4,000 bytes; keep records for 3 years, using 365 days per year. This is raw logical data; indexes, replicas, and backups are excluded.
- An average event-search response is 24,000 bytes. An average booking request body is 2,000 bytes.
- Personalized AI recommendations are not approved for launch and are excluded from these request totals. If asked about their volume, say it is unknown; do not invent it.
- Treat daily totals as logical service requests. Do not infer user counts or additional requests.

Start by asking what I would estimate first. When I say “Time is up,” stop interviewing and assess: average vs peak rates; separate reads and writes; read/write ratio; raw retained storage; inbound vs outbound bandwidth and correct units; explicit ranges and assumptions; and whether an estimate is connected to a later design decision. Use Strong / Adequate / Missing with evidence, challenge my weakest estimate first, then give one improvement. Accept reasonable rounding.

Check yourself — let the workload shape the design

Ten scenarios. Choose the estimate or explanation that preserves the assumptions and units.

Scenario 1

A rehearsal plan says 864,000 search requests per day average 100 RPS because it divided by 8,640 seconds. How should you correct it?

Use 86,400 seconds per day; the average is about 10 RPS
Keep 100 RPS as the average, but ignore the ticket-sale window
Treat 864,000 as registered accounts and ask for active users
Use 10 RPS as full capacity because a daily average covers demand

Scenario 2

An estimate converts all 300,000 Encore accounts into active users and divides their 12 daily searches across the day. The launch event is expected to concentrate traffic. Which revision makes the model more defensible?

Keep every account active and use the daily average as the capacity target
Estimate active share and request rate, then apply a sale-window peak factor
Replace account count with the event's total attendee capacity
Keep the request calculation and add three-year retention to it

Scenario 3

Encore has 14 average read requests/second and a stated 12× event-sale peak. What is the rough peak?

About 14 reads per second during the stated on-sale peak
About 170 reads per second during the stated on-sale peak
About 1,700 reads per second during the stated on-sale peak
About 26 reads per second during the stated on-sale peak

Scenario 4

A teammate applies the read peak factor to booking writes too. What is the best correction?

Assume both read and booking peaks happen at the same rate
Combine the flows into one shared average rate for planning
Ignore booking peaks because writes arrive in short bursts
Apply the booking-specific peak to its own average write rate

Scenario 5

A review notes that Encore has about 25 reads per booking and suggests relaxing the no-double-booking promise. What is the strongest response?

Use a cache for reads but skip strict booking checks
Keep the no-double-booking rule despite read-heavy demand
Count search reads as writes when sizing seat allocation
Relax seat uniqueness during sale peaks to reduce load

Scenario 6

A capacity review needs a three-year raw booking-data baseline before adding indexes or replicas. Using Encore’s supplied facts, what should you report?

About 0.2 decimal GB for the full three-year retention period
About 210 decimal TB for the full three-year retention period
About 210 decimal GB raw before indexes and replicas are added
About 210 decimal MB for the full three-year retention period

Scenario 7

The storage result excludes indexes, replicas, and backups. How should you present it?

Call it raw logical storage and name the omitted overhead
Treat that value as the full capacity that must be provisioned
Add an arbitrary multiplier without explaining what it covers
Drop the calculation since rough estimates are never useful

Scenario 8

The traffic team is sizing the major on-sale window: about 167 search reads/second, each returning 24,000 bytes. Which rough outbound rate should it plan to test?

About 0.34 megabits/second, using average search demand
About 2.7 megabits/second, using average search demand
About 32 megabits/second, using the on-sale read rate
About 2.7 gigabits/second, using an eightfold conversion twice

Scenario 9

A payload may be 12–24 KB, and the resulting bandwidth range crosses a capacity threshold. What should the design team do?

Use only the midpoint so the estimate stays easy to explain
Ignore the range because payload sizes always vary over time
Show both ends and plan to measure the decision-sensitive input
Report the upper estimate as exact and provision exactly to it

Scenario 10

Two estimates differ by 10%, but both imply the same storage choice. What is a useful interview explanation?

Spend the remaining interview time proving which input is exact
Choose the larger estimate and redesign the storage layer
Drop the assumptions because both estimates are close together
Explain the range and why it does not move this decision

You have extended the scope brief into a demand model and named the assumptions that could matter later. Keep the numbers beside their units and their time windows. The next module turns this workload into API, traffic, storage, cache, and search choices.

Primary source — use this as a practice reference

Donne Martin — System Design Primer: interview approach and back-of-the-envelope calculations

The interview guide explicitly prompts candidates to estimate requests per second, data volume, and read/write ratio, then points to estimation tables.

Recommended learning

AWS Well-Architected: Performance Efficiency — relate performance expectations to real workload patterns.
System Design Primer: interview approach and back-of-the-envelope calculations — practice request-rate and data-volume estimates.
Back-Of-The-Envelope Estimation / Capacity Planning — optional estimation walkthrough.
System Design Interview: A Step-By-Step Guide — optional walkthrough including estimation in an interview flow.

References

Donne Martin, System Design Primer — How to approach a system design interview question — workload questions and back-of-the-envelope references.
Amazon Web Services, AWS Well-Architected Framework: Performance Efficiency — performance requirements and workload design.
Microsoft, Build for business needs — traffic bursts and user-scale questions inform design decisions.

Your one tangible winA workload model attached to Encore’s scope brief: average and peak demand, read/write mix, raw storage, bandwidth, and one decision-sensitive assumption.