System Design Requirements and Estimation: Turn Ideas Into Architecture
In Lesson 1, you learned that system design begins with a problem and explicit trade-offs. This lesson supplies the next step: convert a vague product idea into requirements and a small set of estimates that guide the first architecture.
This is not fortune-telling. An estimate is a declared assumption with units, a calculation, and a range. Its purpose is to stop the team from selecting storage, compute, or networking components by habit before it understands the expected workload.
Working outcome
By the end, you will be able to write functional and non-functional requirements, choose an SLO, estimate requests per second, storage, and bandwidth, and explain how each estimate influences an architecture. You will practise with a fictional link-sharing service; the method applies to any product.
Prerequisites
- Complete Lesson 1: System Design foundations and roadmap.
- Comfort with basic multiplication, time units, and HTTP requests.
- A willingness to label unknowns instead of inventing certainty.
Start with a requirements sheet
Imagine a service that creates short links and redirects visitors. Before drawing a database or cache, write what it must do and what good behavior means.
| Type | Example requirement | Why it matters |
|---|---|---|
| Functional | Create a short link for an authenticated user. | Defines an API and durable mapping to store. |
| Functional | Redirect a visitor from a short code to its destination. | Defines the most common read path. |
| Functional | Disable a malicious or expired link. | Creates an administrative and correctness path. |
| Non-functional | Redirects should normally complete quickly. | Guides latency targets, caching, and location choices. |
| Non-functional | Created links must not disappear after an acknowledged write. | Guides durability and backup choices. |
| Constraint | Start with one region and a small operations team. | Prevents premature multi-region complexity. |
Requirements are negotiable product decisions. Ask clarifying questions: Are custom aliases supported? Can destinations change? Is analytics real-time? Is deletion legally required? Are links private? Each answer changes the design more than a preferred database brand does.
Choose measurable objectives
A service-level objective (SLO) makes “fast” and “reliable” testable. For example: “Over a 28-day window, 99.9% of successful redirect requests finish within 250 ms at the service boundary.” This is an example target, not a default to copy. Choose a target that matches user value, risk, and cost.
Keep availability, latency, and durability distinct. An API can answer quickly with stale data; a write can be durable but slow. State which operation the objective applies to and how it is measured.
Estimate traffic with units
Assume the product expects 2.4 million redirects per day and 24,000 new links per day. Divide daily traffic by 86,400 seconds to get an average, then model a peak multiplier. If redirect traffic is uneven and the planned peak is 20 times average, the first capacity hypothesis is approximately 556 redirect requests per second (2,400,000 ÷ 86,400 × 20).
The point is not that 556 is “correct.” The point is that every reviewer can see the assumptions, challenge the peak factor, and recompute the result. Write read/write ratio too: this example has roughly 100 redirect reads for each create write.
Estimate storage and bandwidth
Suppose each durable link record, including indexes and metadata allowance, is budgeted at 1 KB. At 24,000 new links per day, a year adds about 8.8 GB before replication and backup overhead (24,000 × 1 KB × 365). If a redirect response averages 600 bytes, peak egress at 556 requests per second is roughly 334 KB per second before protocol overhead.
These are planning estimates, not a replacement for measurement. Record what is excluded: analytics events, logs, cache replicas, indexes, encryption overhead, and backup copies can dominate a simple record-size calculation.
Let estimates influence the first architecture
The example has a read-heavy, small-record workload. A reasonable first design might use a stateless redirect API, a durable mapping store, and a cache only after measurements show the storage read path needs help. It does not automatically require sharding, a global event stream, or multiple regions.
Conversely, a high write rate, large uploads, or a strict recovery objective would lead to a different design. This is why estimates must come before components: they provide the reason for each added layer.
Validation steps
- Write the units beside every number: requests/day, bytes/record, seconds, or percent.
- Calculate an average and a peak separately; never quietly treat one as the other.
- List the top three assumptions that could change the design.
- Load-test a simple vertical slice once it exists, then replace assumptions with observed limits.
- Review the design when launches, marketing events, or a new feature change demand.
Common mistakes
- Starting with a diagram: diagrams hide missing requirements. Start with user actions and constraints.
- Using a daily average as capacity: systems fail during peaks, not at the arithmetic average.
- Presenting estimates as facts: state ranges and assumptions.
- Ignoring growth and launch traffic: capacity planning needs both expected adoption and planned events.
- Measuring only success: track errors, saturation, queue depth, and dependency latency too.
Production checklist
- Document functional requirements, non-functional objectives, constraints, and out-of-scope features.
- Define how latency, availability, and durability are measured.
- Make read/write mix, peak factor, retention, and growth assumptions visible.
- Use load testing to establish capacity rather than relying on old rules of thumb.
- Review capacity before launches and after meaningful demand changes.
Next lesson
Next, you will follow a request across the network: DNS, HTTP, TLS, APIs, reverse proxies, and load balancers. That builds directly on the traffic and latency requirements you defined here. Continue through the System Design learning track in order.