System Design Starts With Requirements and Constraints

The short answer

System design is the work of choosing how a system meets a particular set of needs. Start by stating what people must do, what quality they expect, what limits you must respect, and what lies inside the design. Only then compare technical options.

For a small link-sharing service, “create a short link” is a requirement. “Use five microservices” is a possible design, not a requirement. The right choice depends on traffic, reliability, cost, team capacity, and existing infrastructure. The Google Cloud Well-Architected Framework similarly connects architecture to use cases, tradeoffs, and operational simplicity.Its guidance is cloud-specific, but the questions are broadly useful.¹

What system design actually means

It connects product behavior to data, computation, communication, failure handling, and operations. A useful design can be one application and one database. A larger design is not automatically more mature. Google Cloud's architecture guidance explicitly recommends starting simply and resisting over-engineering.That is a provider's recommendation, not a rule that every system has identical needs.¹

Begin with the problem

Who has a problem? What action must succeed? Which failure would matter most? For the illustrative link service, perhaps a person creates a short link and another person follows it. Decide whether usage statistics and disabling links are needed now, or merely possible later. A design for unconfirmed features is guesswork.

Functional requirements

Functional requirements say what the system does. A deliberately small version might create a short link, redirect it, disable it, and show basic usage information. Each action suggests an input, result, and error condition. These are behaviors, not product names or cloud services.

Nonfunctional requirements

These describe qualities or limits: expected response time, availability, durability, consistency, scale, security, privacy, operability, and cost. They can conflict. Extra redundancy can increase availability but also cost and operational work. Stronger consistency may constrain some distribution choices. Not every operation needs the same target.

An availability goal concerns whether the service can be used. Durability concerns whether accepted data survives. Low latency concerns how long an operation takes. Google SRE's service-level discussion separates these measures and recommends choosing indicators that matter to users.A numeric target needs a measurement definition; “fast” alone cannot be tested.³

Users and use cases

A visitor following a link and an owner disabling one may have different permission and performance needs. Identify the major actors and their important actions. “All users” can hide a critical distinction between a frequent read and a rare write.

System boundaries

The boundary says what you are designing. The browser, link API, and stored mappings might be in scope; an external identity service may be a dependency; billing or analytics might be out of scope. AWS Well-Architected's workload-and-scope guidance treats scope as an explicit review decision.A boundary is not necessarily a team boundary or repository boundary.²

Constraints

Constraints narrow viable choices. Examples: one development team, a fixed hosting budget, existing database expertise, a release deadline, or a legal data-handling requirement. Security and regulatory constraints must be verified for the actual project; this article does not invent any for the example.

Assumptions

When a number is unknown, label an assumption rather than disguising it as fact: “Assume redirects greatly outnumber link creations; verify after launch.” Record what decision depends on it and when to revisit it. An assumption is not a production measurement.

Traffic patterns

Ask about active users, average and peak requests per second, bursts, read-to-write ratio, request sizes, geography, and critical operations. A redirect-heavy service differs from one with frequent edits. Do not turn a daily-user count directly into server capacity; the next lesson shows how to make an explicit rough estimate.

Data characteristics

What must be stored? How much arrives, how long is it retained, and who may read or change it? For a short link, the mapping is essential; optional click analytics can have different volume and retention needs. A read-heavy mapping workload and a write-heavy event workload need not share one access strategy.

Reliability expectations

Ask which failures are acceptable, for how long, and for whom. An internal reporting page and a public redirect endpoint may have different availability expectations. Define whether a successful write must survive process restarts. Reliability goals should be testable and proportionate, not automatically “five nines.”

Security and privacy requirements

Identify sensitive data, abuse risks, permissions, retention, and external sharing before selecting storage or logging. A public redirect service may need protection against malicious destinations or abuse, but this example does not prescribe a complete security design. Specific controls depend on the threat model.

Cost and operational constraints

The team must be able to deploy, monitor, repair, and pay for the system. Managed services may reduce some operational work but add pricing and provider tradeoffs. A more distributed design can create more failure boundaries. Include operational skill and on-call capacity in the choice.

What not to design yet

Do not choose a queue, cache, load balancer, database family, or microservice boundary just because it appears in an example diagram. First ask which requirement each component serves. The backend request lesson already covers the application flow; system design asks whether that flow meets the stated workload and failure goals.

A small design exercise

For the link service, write four functional actions, one boundary, and three unknowns. For example: are redirects far more frequent than edits; must a disabled link stop working immediately; and what outage duration is acceptable? Name the assumption behind each tentative answer. Do not draw infrastructure yet.

Common misconceptions

Design-review scenario

Why this matters when reviewing AI-generated designs

An assistant does not know real traffic, budget, team size, sensitive data, or operational expertise unless given that context. A plausible diagram can hide invented assumptions. Ask it to separate known facts from assumptions, show the tradeoff of each component, and state what evidence would change the recommendation.

Knowledge check

What to learn next