From "we have 50,000 users" to requests per second

The deck says 50,000 users. The architecture review is on Thursday and somebody has to say what that means in requests a second, because every other number on the page depends on it.

Nobody in the room has an access log. You have four steps and about ninety seconds.

What is the peak request rate for 50,000 daily users of an ordinary web product? Commit to a figure.

Predict

Fifty thousand daily active users of an ordinary web product. What is the peak rate in requests per second?

Choose one answer

A few thousand a secondSomewhere around a hundred and fiftyAbout twenty-five a secondImpossible to say without knowing the product

Lock in answer

QPS from usage

≈ Hypothetical model, not a forecast

Converts daily active users and actions per day into average and peak requests per second, split into reads and writes. Rows sweep the user count from zero up to the chosen figure, so period is users rather than time.

It assumes

• Fifty thousand daily active users, all of them active on the same day.
• Forty server-reaching requests each per day, which is a product people open a few times daily.
• Peak load is six times the flat daily average, for reads and writes alike.
• Twenty reads for every write, which is ordinary for a product people mostly browse.
• One user action produces exactly one request, so no retries and no client-side fan-out.

It ignores

• Weekly and seasonal shape — a Monday and a Sunday are not the same day
• Background work: cron jobs, migrations, analytics and replication traffic
• That reads and writes cost wildly different amounts of the same server
• Retries, which turn one user action into several requests under load

Hold the fifty thousand users still. Find a combination that takes the peak rate past 500 requests a second, then check what the reads-per-write slider did to that total on the way.

Daily active users50,000

Actions per user per day40

Peak as a multiple of average6

Reads per write20

Zero means every action writes. Most consumer products sit between 10 and 100.

Actions per day

2,000,000

Average requests per second

23.15/s

Peak requests per second

139/s

Average reads per second

22.05/s

Average writes per second

1.1/s

Peak reads per second

132/s

Peak writes per second

6.61/s

Share of actions that are reads

0.952

Average gap between writes

907 ms

• Peak reads per second
• Peak writes per second

◷ Not there yet — keep moving the controls.

Two million actions a day. 23 requests a second average, 139 at peak. Of that peak, 132 are reads and 6.6 are writes.

Sit with the write figure for a second, because it is the one that decides your database. The model turns it round for you: at this load the average gap between writes is 907 milliseconds. A service where a write arrives roughly once a second does not need a distributed datastore, a write-optimised engine, or anything else that exists to absorb writes. It needs one Postgres.

That conversion — a rate into the gap between events — is worth doing every time, because "6.6 writes a second" and "a write every nine-tenths of a second" produce visibly different architecture conversations in the same room about the same number.

What I would actually do instead of this

If the service exists, do not estimate. The number is already recorded in three places and all of them are quicker than the arithmetic.

The load balancer's own metric. RequestCount on an AWS Application Load Balancer, or the equivalent on any managed load balancer, at one-minute resolution. Take the maximum one-minute bucket over the last month, divide by 60, and you have the measured peak rather than an assumed one.

The access log. One line per request with a timestamp, which means awk '{print $4}' access.log | uniq -c | sort -rn | head gets you the busiest second of the day in one command. This also gives you the real peak-to-average ratio, which is the input most worth replacing with a measurement.

The database. pg_stat_database has xact_commit; the difference between two samples a minute apart, divided by 60, is your write rate including the writes your application does without anybody asking it to.

The arithmetic is for the service that does not exist yet. For one that does, an estimate that disagrees with the log is not a second opinion.

Check

Somebody points out that the real figure is 50,000 registered users, and daily active is closer to 8,000. What happens to the estimate?

Choose one answer

It falls by a factor of about six, to roughly 22 at peakNothing much, because peak is dominated by the peak multipleIt falls, and the actions per user should rise to compensateThe estimate was never useful, since both numbers were guesses

Check answer

Where the division by 86,400 stops working

The condition is sharp and it arrives often: when traffic peaks far more sharply than six times the average.

Six assumes human beings spreading their activity over waking hours. These things do not:

A push notification to every user. The resulting burst lands in the first thirty seconds and is a peak-to-average ratio in the hundreds, not the single digits.

A cron job everyone wrote for midnight. Your own traffic, self-inflicted, all at once.

A market open, a ticket release, a flash sale. Load arrives on a clock somebody else controls.

Bots and crawlers, which do not sleep and flatten your daily curve while adding to it.

When any of those is in the picture, the daily total is the wrong input entirely. Size the burst: how many events arrive, over how many seconds, and what happens to the ones you cannot serve inside that window. The answer is usually a queue and a stated drain time rather than a bigger serving tier, which is a different lesson and a different model.

Worth remembering

• Four steps: daily active users, actions each per day, divide by 86,400, multiply by the peak-to-average ratio.
• Fifty thousand users at forty actions each is two million a day, 23 requests a second average and 139 at a six-times peak.
• Split the peak into reads and writes: 132 reads and 6.6 writes a second size completely different things.
• Convert a write rate into the gap between writes — a write every nine-tenths of a second produces a different architecture conversation from 6.6 writes a second.
• Registered users and daily active users routinely differ by an order of magnitude, and using the wrong one is the most common error in the whole estimate.
• The estimate is linear in every input, so a correction to any of them is a ten-second fix if the inputs were written down.
• If the service exists, read the load balancer's request count or the access log instead; the arithmetic is for services that do not exist yet.
• Pushed notifications, cron jobs, market opens and sales produce peak-to-average ratios in the hundreds, and then the daily total is the wrong input and you size the burst.