Estimating Servers for a Real Service

In one line: 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.

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.

Always run the plausibility test

Judge whether your numbers are reasonable before you present them. Estimating two servers for a service with hundreds of millions of daily active users is obviously wrong — no organization at that scale runs on two machines, and you know that without doing any arithmetic.

When a result fails the smell test, the arithmetic is usually fine and an assumption is broken. Say so out loud and go find it:

"That gives me two servers, which is clearly wrong for a service this size. The problem is my uniform-distribution assumption — real traffic peaks. Let me redo this with a realistic peak load."

Catching your own error is a strong signal. Presenting "two servers" with a straight face is a fatal one.

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.