Estimating QPS, Storage, and Bandwidth

Almost every estimation question in an interview is one of three calculations, or a combination of them. How much traffic, how much data kept, and how much data moved.

Each one starts from the same place: a number of users, and an assumption about what each user does per day.

Traffic

QPS stands for queries per second. It is how many requests the system handles each second, and it is the number that decides how many servers you need.

Start with writes, because writes are usually the smaller and better understood number, then derive reads from them.

The chain has four steps.

1. Daily active users times actions per user gives actions per day.
2. Divide by 100,000 to get the average per second.
3. Multiply by the read to write ratio to get read traffic from write traffic.
4. Multiply by two or three for peak.

The read to write ratio deserves its own assumption, stated out loud. A social feed might be read a hundred times for every post written. A logging system might be written constantly and read almost never. The ratio decides whether the design is about handling writes or about serving reads, and those lead to different systems.

Storage

Storage is the amount of new data written each day, multiplied by how long you keep it.

Two multipliers get forgotten, and both matter.

Retention. Data kept for five years is 1,825 times the daily figure. Whether the requirement is to keep everything forever or to delete after 30 days changes the answer by orders of magnitude, so it is worth asking.

Replication. Data is stored more than once so that losing a machine does not lose the data. A replication factor of three is a common default, and it triples the storage bill. An estimate that leaves it out is low by a factor of three before anything else goes wrong.

Metadata is the third multiplier and usually the smallest. The row describing a photo is tiny next to the photo, so for large objects it can be ignored. For small objects it cannot: a system storing short text posts may spend more on indexes and metadata than on the posts.

Bandwidth

Bandwidth is data per second, so it is QPS multiplied by the size of one object.

Do it twice, because the two directions are rarely the same size.

Incoming is write QPS times the size of what is uploaded. Outgoing is read QPS times the size of what is served.

In a read heavy system these two numbers are wildly different, and the outgoing number is often the first result that looks alarming. That is a useful moment rather than a problem: a large outgoing figure is the evidence for putting a content delivery network in front of the service, so that most of those bytes are served from somewhere near the user instead of from the origin.

A fourth calculation worth knowing

How much memory a cache needs.

The usual assumption is that a small share of the content gets most of the requests, often stated as 20 percent of the objects serving 80 percent of the reads. Estimating cache size then means taking the objects accessed in a day, keeping a fifth of them, and multiplying by the object size.

The result answers a real design question: whether the working set fits in the memory of a few machines, or whether the cache itself has to be distributed across many.

The order to do them in

Each row uses a result from the row above it, which is why the order is fixed. Doing them in this order also means a corrected assumption flows forward: if the interviewer changes the user count, you redo step one and every later number follows.

💡 State the unit at every step and say it aloud. Requests per second, bytes per day, bytes per second. Most estimation mistakes that reach an absurd answer are unit errors, and saying the unit is how you catch one while it is still cheap to fix.

Key takeaway: Traffic comes from daily active users times actions per user, divided by 100,000 seconds, adjusted by the read to write ratio and multiplied by two or three for peak. Storage is writes per day times object size times retention, then multiplied by the replication factor, which is commonly three. Bandwidth is QPS times object size, calculated separately for incoming and outgoing traffic. Cache size comes from the share of objects that serve most of the reads. Do them in that order, because each calculation feeds the next.

The next lesson, A Worked Estimation Example, runs all four calculations end to end on one system.