From Active Users to Average and Peak QPS

01 The idea

The problem this lesson solves

100,000 daily users making 10 redirects each produce 1,000,000 redirects/day.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

A user count becomes a request rate only after you specify active users, actions and a time interval.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Start from daily actions

100,000 users × 10 redirects = 1,000,000 redirects per day. A day has 86,400 seconds, so average read traffic is 1,000,000 ÷ 86,400 ≈ 11.57 QPS. A 5× peak assumption gives 57.87 read QPS. The average write rate is 10,000 ÷ 86,400 ≈ 0.116 QPS; if writes share the same peak factor, peak writes are 0.579 QPS. Keep raw values until the end and round capacity upward, not every intermediate quantity.

Peak is a hypothesis to test

A daily average hides time zones, lunch peaks and launch events. A synchronized burst can overwhelm a service whose daily average looks tiny. Label the peak factor as an assumption and ask how it was measured. If one event produces 100,000 requests in ten seconds, that burst is 10,000 QPS regardless of the day's average. A queue can absorb some delayed work, but an interactive redirect has a different waiting budget from an asynchronous report.

Keep units in every line

Our workload has 100,000 daily active users and ten redirects per user per day. Multiplication gives one million redirects per day, not one million per second. Divide by 86,400 seconds per day to obtain approximately 11.57 redirects per second on average. A five-times peak assumption produces about 57.87 redirect QPS.

Write requests/day and seconds/day beside the numbers so the units visibly cancel. A number without a unit is easy to reuse incorrectly in a storage or bandwidth estimate. Keep unrounded intermediate values and round only the reported result or required capacity.

Reads and writes have different paths

Ten thousand new links per day average about 0.116 creation requests per second. At the same modeled peak multiplier that becomes about 0.579 write QPS. A cache can remove many mapping reads but does not make link creations disappear. Authentication and analytics may also add operations, so distinguish client requests from internal database queries.

One request can trigger several queries or no query on a cache hit. State which boundary the rate counts. The app, limiter, cache and database can all see different QPS even while serving the same external users.

A daily multiplier can miss a synchronized event

If 60,000 users open a link in five seconds, that event alone produces 12,000 QPS during those seconds. The daily average may still look modest. A queue can delay asynchronous work, but a redirect must fit an interactive waiting budget.

Use a traffic shape appropriate to the feature: sale starts, notification fan-out and classroom launches can synchronize users. Treat a five-times multiplier as an assumption to validate, not a property of all internet workloads. The console compares warm and cold cache demand after the same external peak; the next lessons develop the other capacity budgets.

Guided tutorial

1. Create a unit table

List daily users, reads/user/day, new links/day and assumed peak multiplier.

2. Calculate average reads

Multiply actions, then divide by 86,400.

3. Calculate writes separately

Apply the same steps to creations and label the different rate.

4. Challenge the peak

Add a synchronized launch event and compare its short-window rate with the multiplier model.

daily_reads = 100000 * 10
average_read_qps = daily_reads / 86400
peak_read_qps = average_read_qps * 5
average_write_qps = 10000 / 86400
peak_write_qps = average_write_qps * 5
# Console also shows database reads after cache hits.

05 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

06 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

07 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

08 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions