SD1.3 · LESSON 3 OF 6

Workload estimates

Turn a product requirement into a workload model, measurable objectives and a justified initial capacity estimate.

THE IDEA

From users to requests per second

The formula is simple: average rate = daily active users x actions per user per day / 86,400 seconds. For Pixelfold the four dominant operations add up to 39.5 actions per user per day (25 feed loads, 6 photo opens, 0.5 uploads, 8 likes, all assumptions). With 200,000 daily active users:

The arithmetic

200,000 users x 39.5 actions = 7,900,000 requests per day
7,900,000 / 86,400            = 91.4 requests per second on average

Which users? Daily active, not registered. Pixelfold has 5,000,000 accounts but most are dormant. Using the registered count would give 2,285.9 requests per second, an estimate 25 times too high, and you would buy servers for people who are not there.

Traffic is not flat: peak and burst

People are not evenly spread across the day. The average is the wrong number to size for, because a system must handle its busiest period. Below, a smooth day-night curve with a mean of exactly 1 is multiplied by the average. Move the sliders. The peak weight is 1 plus the swing, and a short burst multiplies the busiest hour again.

Daily active users 200,000Day-night swing 0.80Evening burst 1.5x

traffic by hour (curve only)daily averageplanning peak (curve x burst)

Average91.4 req/s

39.5 actions per user per day

Peak weight1.80x

1 + swing

Planning peak246.9 req/s

2.70x the average

The shape is an assumption with a mean of exactly 1, so the swing never changes the daily total, only how bunched it is. Measure your own curve once you have real traffic.

Planning peak = average x peak weight x burst. With the case-study defaults: 91.4 x 1.8 x 1.5 = 246.9 requests per second.

Predict first. Daily active users double and the shape of the day does not change. What happens to the planning peak?

Requests in flight, and the registered-users trap

"One million registered users" does not mean one million simultaneous requests. Little's law says the number of requests inside the system at once equals the arrival rate times the time each one stays. At the planning peak with an 80 ms mean, that is 246.9 x 0.08 = 19.75 requests in flight. This number later helps size connection pools and thread counts.

Arrival rate 250 req/sMean time in system 80 ms

Requests in flight20.0

rate x time, with time in seconds

Five million registered users do not make five million simultaneous requests. A few hundred requests per second at tens of milliseconds each is a few dozen in flight.

In flight = rate x time in system (seconds).

Chapter context

System design starts with what the system must do and the conditions under which it must do it. A component diagram is only useful when its choices can be traced back to access patterns, data volume, latency targets and failure expectations.

TRY IT YOURSELF

Pixelfold has 5,000,000 registered accounts and 200,000 daily active users. The four dominant operations are below. Work out the load the backend must be sized for. Use a calculator or the console of your choice, the checks use your numbers.

Operation	per daily user per day
Upload a photo	0.5
Load my feed (recent photos from people I follow)	25
Open a single photo	6
Like a photo	8

daily curve: 1 + 0.8 cos(2 pi (hour - 20) / 24)

An evening burst multiplies the busiest hour by 1.5. Seconds per day: 86,400.

Which count drives daily traffic?

Average req/s Peak weight Planning peak req/s

In flight at peak (80 ms mean) Planning peak at 400,000 DAU

Checks (0 of 6)

Pick the user count that drives daily traffic
Average requests per second over the day (4 operations, 200,000 DAU)
Peak-hour weight from the daily curve (peak hour divided by the daily average)
Planning peak in requests per second, including the 1.5x evening burst
Requests in flight at the planning peak when mean latency is 80 ms
Planning peak if daily active users double to 400,000

Stuck, or something not working? You can come back to it any time.

CHECK YOUR UNDERSTANDING

Do one million registered users imply one million simultaneous requests?

ANoBYes

Chapter reference: math, worked example & code

This section belongs to the whole chapter, so it is the same on every lesson in it and may cover a different lesson's topic. The code for the experiment you just ran is inside the experiment itself.

Math and notation

For U daily active users and a requests per user per day:

R_{avg}=Ua/86400,\quad R_{peak}=pR_{avg},\quad n=\lceil R_{peak}/(cu)\rceil.

Here p is a peak multiplier, c measured capacity per instance and u a chosen usable fraction. The multiplier and capacity are workload assumptions, not universal constants.

Worked example

Assume 100,000 daily users, 20 requests each and a peak multiplier of 10. Average demand is 2,000,000/86,400≈23.15 requests/s and estimated peak is 231.48 requests/s. An instance sustaining 100 requests/s with usable fraction 0.6 contributes 60 requests/s, so four instances cover the estimated peak. Five are needed to retain that same usable capacity after losing one instance.

Reference code

The following example uses the Python standard library and does not call a remote service.

from math import ceil,isclose
average=100_000*20/86400
peak=10*average
usable=100*.6
assert isclose(average,23.14814814814815)
assert ceil(peak/usable) == 4
assert (5-1)*usable >= peak
assert (4-1)*usable < peak

Python examples are provided for study and local execution; this page does not execute Python.

Common mistakes

Average traffic is not peak traffic. A headroom assumption is not measured performance. Durability, correctness and availability need separate objectives.