Load Estimation

Basic System Design
≈ 2 min read

Architecture must match the scale

The same feature can be implemented very differently for one hundred users and for one hundred million. That is why, after requirements and architecture trade-offs, the next question is: what load does the system actually need to handle?

System Design does not require guessing exact numbers down to the last byte. You need to quickly get the order of magnitude: how many requests arrive, how strong the peaks are, how much data accumulates, and how much data flows through the system. These estimates help you see where a simple solution is enough and where additional scale headroom is already needed.

What we will cover

  • Load Estimation Basics. We will learn how to translate product inputs into technical quantities, state assumptions, and avoid false precision.
  • RPS and QPS. We will see how to estimate request intensity and why the number of HTTP requests does not always match the number of calls to internal systems.
  • Peak Load. We will look at why an average is not enough and how to leave realistic headroom for periods of increased activity.
  • Storage Estimation. We will learn how to estimate how much data appears per day, per year, or over a chosen retention period.
  • Bandwidth Estimation. We will connect request or response size with request count and estimate the resulting network traffic.
  • Back-of-the-Envelope Calculations. We will combine separate estimates into a quick model that helps make architecture decisions without building a complex simulation.

The topics move from inputs to an overall picture of scale: first we state assumptions, then estimate request flow, peaks, storage, and network traffic, and finally learn to combine them into one quick model. After that, it makes sense to move on to system components and choose them with a clear understanding of the expected load.

The goal of estimation is not to predict the future down to the last unit. Its purpose is to distinguish a system serving hundreds of requests per second from one serving hundreds of thousands and to notice likely bottlenecks early.