Concepts
Requirements and capacity estimation
Intuition
Before building a bridge, the engineer asks what it needs to do (carry cars or only pedestrians?), how many people will cross at the busiest hour, and how much closure time per year is acceptable. Then they do quick back-of-the-envelope math to tell whether the project is the size of a footbridge or a highway, and write down the assumptions they used so others can disagree with them. In systems it is the same: first you agree on what the system should do and how good it needs to be, then you estimate the size of the problem, without precision, just to get the order of magnitude right.
How it works
Functional requirements say what the system does (create an order, shorten a URL, redirect); non-functional requirements say how well: availability, latency, durability, consistency, and scale. An SLI (service level indicator) is the measured metric, such as the fraction of successful requests; an SLO (service level objective) is the target on that metric. The availability target translates into a downtime budget: a year has 365 x 24 = 8,760 h, so 99% allows 1% x 8,760 = 87.6 h (about 3.65 days), 99.9% allows 0.1% x 8,760 = 8.76 h, 99.99% allows 0.01% x 8,760 = 0.876 h = 52.56 min (about 52.6 min), and 99.999% allows about 5.26 min per year. Load estimation follows the chain users x actions x bytes. A day has 24 x 3,600 = 86,400 s. Example with stated assumptions: 10 million DAU (daily active users) x 2 writes per user = 20 million writes/day; divided by 86,400 that gives about 231 writes/s of average QPS. With a read:write ratio of 10:1, that is 200 million reads/day, about 2,315 reads/s. The system is sized for peak QPS, not the average: with a 3x peak factor, writes reach about 694/s and reads about 6,944/s. For storage, 20 million writes/day x 1 KB = 20 GB/day, x 365 = 7.3 TB per year, before multiplying by the replication factor (with 3 replicas, about 21.9 TB). For bandwidth, QPS x bytes per request: 6,944 reads/s x 1 KB, about 6.9 MB/s, or about 55 Mbit/s. Latency is budgeted too: the end-to-end target (for example, p99 under 200 ms) is split across the hops in the path (network, service, cache, database), and the order-of-magnitude numbers for each hop tell you whether the budget closes. The result is compared with the reference capacity of a component (for example, a single database primary) to decide whether scaling vertically is enough or whether you need a cache, a queue, or sharding. Each step is done with written assumptions, so the calculation is verifiable and correctable.
In practice
In interviews and in design reviews, the first phase is clarifying requirements and scale, and the second is a back-of-the-envelope calculation that shows where the bottleneck is: read-dominated systems call for caches and replicas, and write-dominated or high-peak systems call for queues and partitioning. Canonical references: the chapter on service level objectives in Google's Site Reliability Engineering book (SLI, SLO, SLA, and error budget) and the list 'latency numbers every programmer should know', popularized by Jeff Dean, for estimating the latency of each hop. Good practice is to round conservatively, show the derivation, and say which assumption would change the decision, instead of presenting a number with no origin.
Use it in a design
Practice the cases that rely on this concept in the System Design school.