System Design: Choosing Parts Against Requirements

System design is choosing the parts of a software system, and how they connect, so that it meets a stated list of requirements. A requirement is something the finished system must do, or a standard it must reach. The design is good when it meets those requirements at a cost the team can carry, and there is no other test of it.

Two teams, one product. Picture two teams asked to build the same online shop. The first is told the shop must be "fast". The second is told it must be "99.9% available", which means it may be down for less than nine hours a year. The first team puts a cache in front of the database so pages load quickly. The second team runs two copies of every part, so that one can fail while the other carries on. Both built a reasonable system, and the two systems are different, because each team designed against a different requirement.

Every choice trades one quality for another. The cache makes pages faster, and it also means some readers see a price that changed a minute ago. The second copy of every part makes the shop survive a failure, and it doubles the bill. No design is best at everything, so the requirements decide which trade is worth making.

The loop. The System Design Primer, a widely used open guide, describes the work as four steps. You gather the requirements, estimate the load they imply, sketch a high-level design of the main parts, and then look closely at the parts most likely to fail. A deep look often shows a requirement nobody asked about, which sends you back to the first step.

What it is not. Choosing a framework or a programming language is not system design, because neither changes which parts exist or how requests flow between them. Drawing boxes with no requirement behind them is not design either: it is a picture nobody can check.

So when someone shows you a diagram, the first question to ask is which requirement each box is there to meet.