What a Back-of-the-Envelope Calculation Is

Why this matters: you cannot defend an architecture you haven't sized. A BOTEC is the fastest path from "here's my design" to "here's why this design is physically possible," and it takes about ninety seconds once you know the numbers.

Key takeaway

Back-of-the-envelope calculations (BOTECs) are quick, approximate estimations typically performed on paper. They are not intended to yield precise results — they provide a preliminary evaluation of a system's feasibility and critical parameters.

The idea, outside of software

To estimate a neighborhood's population, you could count the houses in a small sample area and multiply by the average household size. That is dramatically faster than conducting a full census, and for most decisions it is entirely good enough.

That is the whole method: sample something you can measure, multiply by something you can reason about, and sanity-check the result. The same approach validates data and tests assumptions in system design.

Why system design needs them

Modern systems consist of many interconnected computational components. Architectures vary — monolithic, microservices — but accounting for every node type, load balancer, cache, and database is impractical in a time-limited design interview. BOTECs let you estimate capacity and resource requirements without modeling every infrastructure component.

Common estimations include:

Concurrent TCP connections a server can support.
Requests per second (RPS) a web, database, or cache server can handle.
Storage requirements for a service.

The method is to abstract away hardware specifics, latencies, and throughput rates. This chapter first examines server types and latencies — the system's actual reality — and then simplifies those details to estimate RPS, bandwidth, and storage capacity.

Abstracting away real complexity

Real services are genuinely complicated. A single user request may traverse a load balancer, several microservices, a cache tier, and multiple databases, fanning out and rejoining along the way.

That three-box picture is a deliberate abstraction of a system that might contain dozens of services. Considering every variable during a time-limited interview is impractical — and, more importantly, unnecessary, because the conclusions you need rarely depend on that detail.

BOTECs are valuable for making high-level estimates and decisions early in the design process, when the question is still "is this shape of system viable at all?"

What a BOTEC is for — and what it isn't

Use a BOTEC to...	Do NOT use a BOTEC to...
Check whether a design is physically feasible	Set a production capacity plan
Find which resource is the binding constraint	Justify a purchase order
Compare two architectures by order of magnitude	Predict p99 latency
Decide whether a component is even needed	Replace load testing or monitoring

The three-step shape

Nearly every estimation in this chapter follows the same rhythm:

Step 3 is the one people skip and the one interviewers watch for. An estimate you don't sanity-check is a number, not an argument.