Estimating Requests a Second From Daily Users

Five million readers a day becomes about 1,700 requests a second, and the peak is higher.

Requests a second is the number most design choices hang on, and it comes from three multiplications: daily users, times actions each, divided by the seconds in a day, then times a peak factor. Here the method is applied to a news site, one step at a time.

The assumptions. The site has five million daily active users, meaning distinct people who visit at least once a day. Each reads about 30 pages a day. Each page view is counted as one request to the application servers; images and scripts come from elsewhere and are left out.

From daily users to peak requests a second

Count the daily total

Multiply users by actions each: 5,000,000 × 30 = 150,000,000 page views a day.

Divide by the seconds in a day

150,000,000 ÷ 86,400 = about 1,736 requests a second. That is the average across a whole day, night included. Using 100,000 seconds instead gives 1,500, close enough when all you need is "thousands, not millions".

Apply a peak factor

Traffic is never spread evenly: readers arrive in the morning and evening, and few read at four in the morning. Estimates commonly multiply the average by 2 to 5 for the busiest hour. Taking three for a news site gives 1,736 × 3 = about 5,200 requests a second at peak.

Turn the peak into servers

If one application server handles about 2,000 requests a second, the peak needs 5,200 ÷ 2,000 = 2.6, rounded up to three servers. The number a server handles is itself an assumption, best taken from a measurement of your own code.

What each step decides. The daily total tells you the scale of logging and analytics. The average tells you the steady load, which decides the monthly bill. The peak decides how many servers must exist at the busiest moment, and therefore whether a single machine could ever be enough.

Where the estimate is weakest. The peak factor is a guess until you have traffic to measure, and a news site on the day of a big story can see far more than three times its average. Write the factor down as an assumption, so the person reading the estimate can see where to push on it.

So three multiplications, users times actions, divided by seconds, times a peak factor, turn a product's audience into the load the design must carry.

System Design
Performance

← → move through sections and cards