Estimating Servers for a Real Service

Why this matters: this is the calculation you will actually be asked to perform. It takes thirty seconds, produces a wrong answer, and the entire value lies in noticing why it's wrong.

Key takeaway

Dividing daily requests by seconds in a day gives you a lower bound on resources, because it assumes traffic is perfectly uniform. Real traffic never is — so treat this number as a floor to be corrected, not an answer.

The setup

We apply the estimation techniques to a Twitter-like service, starting from baseline assumptions:

Daily active users (DAU)   = 500 million
Requests per user per day  = 20
Single server capacity     = 64,000 RPS   (the 64-core box from Lesson 5)

The calculation

Quantity	Value	Unit
Daily active users (DAU)	500	Million
Requests on average / user / day	20
Total requests / day	10	Billion
Total requests / second	115	K
Total servers required	2

Working it through:

Total requests/day    = 500M * 20            = 10 billion
Total requests/second = 10 billion / 86,400  = ~115,000 (115K)
Servers required      = 115,000 / 64,000     = ~2 servers

Two servers. For five hundred million daily active users.

The hidden assumption

There is a load-bearing assumption buried in the second line. When we divided daily user requests by the number of seconds in a day, we assumed those requests were uniformly distributed over those seconds — that traffic at 4 a.m. exactly matches traffic at 9 p.m., every day, forever.

Rarely will a service get such a nice, uniform distribution of requests.

Dividing by seconds in a day is a simple strategy, and what it produces is a lower bound on the respective resource. It is genuinely useful — it tells you the floor below which the design certainly cannot work — but it is not a capacity plan.

Why the lower bound is still worth computing

It would be reasonable to ask why you'd bother with a number you know is wrong. Three reasons:

What the lower bound gives you	Why it matters
A floor	If even the optimistic case needs 10,000 servers, the design is dead and you've learned that in ten seconds
A baseline to correct	Peak modeling is a multiplier on this number — you need it first
A sense of the constraint	2 servers means compute is cheap here and something else (storage, bandwidth) will be the real limit

That last row is the most useful output of this particular calculation. Compute is not Twitter's problem — 115K RPS spread over 64,000-RPS machines is trivial. As later lessons show, storage and bandwidth are where the real numbers live.

Key takeaway

Compute the uniform-distribution estimate first because it's fast and gives you a floor. Then immediately state that it assumes uniform traffic, and correct it. The correction is the next lesson, and it changes the answer by four orders of magnitude.

Interview signal by level

Level	What a strong answer sounds like
L4	Computes 2 servers and moves on.
L5	Notices the flaw: "that assumes uniform traffic, which isn't realistic — peak will be much higher."
Staff+	Uses the number correctly: "2 servers is a lower bound and it fails the plausibility test, but it tells me compute isn't the constraint here. The interesting limits will be storage and egress — let me size the peak properly and then go there."

Next: modeling the peak, where this estimate goes from 2 servers to 157,000.