From Requirements to Architecture

Introduction

A product manager walks into the sprint planning meeting and says: “We need to support ten times the current user load by Q3.” Three engineers hear three different things. One thinks about database indexing. One thinks about horizontal scaling. One thinks about caching. All three are correct — and none of them has enough information to start building.

The gap between a product requirement and an architecture decision is not technical. It is analytical. Before a single component is chosen, the system’s behaviour must be characterised numerically: how many reads per second, how many writes, how much data, how consistent, how available, how fast. Requirements without numbers are not actionable. This chapter closes that gap with a systematic translation process.

The Problem

Given a product description, produce a quantified characterisation of the system’s demands: read and write QPS, storage volume, bandwidth, consistency requirements, and latency targets. From this characterisation, determine the architectural constraints that eliminate whole categories of solutions and narrow the design space to a tractable set of choices.

The challenge is that product requirements are stated in user terms (“users can post and read messages”) and must be translated into engineering terms (“1,200 write QPS, 120,000 read QPS, 180 TB storage over five years”) before any meaningful architecture work can begin.

Naive Approach and Why It Fails

The naive approach is to skip estimation and design for “scale” in the abstract — adding a load balancer, a caching layer, and read replicas because “that’s what scalable systems look like.” This produces an architecture that looks sophisticated but may be wildly over- or under-engineered for the actual load.

Over-engineering at low scale adds operational complexity that slows the team down. Under-engineering at high scale produces systems that fall over under real load. A URL shortener does not need a distributed Cassandra cluster at ten thousand daily active users. A social network with one hundred million DAU cannot survive on a single relational database.

The second failure: ignoring the read/write ratio. A system that is 95% reads requires a completely different architecture from one that is 95% writes. Read-heavy systems benefit from caching and read replicas. Write-heavy systems benefit from async ingest, write buffers, and append-only logs. Treating both the same produces a design that serves neither well.

Architecture Walkthrough

Step 1: Separate Functional from Non-Functional Requirements

Functional requirements describe what the system does. Non-functional requirements describe how well.

Functional (URL shortener):
  - User submits a long URL, receives a short code
  - User submits a short code, is redirected to the long URL
  - User can view click statistics for their URLs

Non-functional:
  - Redirect latency: p99 < 20ms
  - Availability: 99.99% (52 minutes/year downtime)
  - Read QPS: 10,000 redirects/sec at peak
  - Write QPS: 100 new URLs/sec
  - Data retention: 5 years
  - Consistency: eventual acceptable for click counts

Non-functional requirements are where architecture decisions live. The latency target of 20ms at p99 immediately implies caching — a database-only redirect cannot achieve that at 10,000 QPS. The 99.99% availability target implies redundancy and no single points of failure.

Step 2: Back-of-Envelope Estimation

Estimation uses four standard conversions:

Time:    1 day = 86,400 seconds ≈ 10^5
Storage: 1 char ≈ 1 byte; 1 KB = 10^3 bytes; 1 MB = 10^6; 1 GB = 10^9; 1 TB = 10^12
Network: typical server NIC = 1–10 Gbps = 125 MB/s – 1.25 GB/s
Memory:  typical server RAM = 64–256 GB

QPS formula: events_per_day / 86,400
Storage formula: records_per_day × record_size × retention_days
Bandwidth formula: QPS × average_response_size

Worked example for a messaging system with 100M DAU:

Write QPS:
  100M users × 10 messages/day / 86,400 ≈ 11,600 writes/sec ≈ 12,000

Read QPS (read:write ratio = 10:1):
  12,000 × 10 = 120,000 reads/sec

Storage per message: 1 KB (text + metadata)
Daily storage: 12,000 × 86,400 × 1 KB = 1,036,800,000 KB ≈ 1 TB/day
5-year storage: 1 TB × 365 × 5 = 1,825 TB ≈ 1.8 PB

Bandwidth (reads): 120,000 reads/sec × 1 KB = 120 MB/s

These numbers immediately constrain the architecture. 1.8 PB rules out a single server. 120,000 reads/sec rules out an uncached database. 12,000 writes/sec rules out synchronous write acknowledgement on anything slower than an SSD-backed system.

Step 3: Characterise the Read/Write Profile

The read/write ratio determines the primary architectural pattern.

Read-heavy (ratio > 10:1): caching is essential. Read replicas reduce load on the primary. CDN handles static or slowly-changing data. The design optimises for fast reads and tolerates slightly higher write latency.

Write-heavy (ratio < 2:1): buffered write paths matter. Async queues absorb write spikes. Append-only logs are cheaper than random-write databases. The design optimises for write throughput and may batch or delay reads.

Balanced (ratio 2:1 to 10:1): no single optimisation dominates. OLTP databases handle this well up to a point. Horizontal sharding is the first evolution step.

Step 4: Determine Consistency Requirements

Consistency requirements determine which storage and replication strategies are admissible.

Strong consistency: every read sees the most recent write. Required for financial transactions, inventory counts, authentication state. Forces synchronous replication. Rules out multi-region active-active without coordination.

Eventual consistency: reads may see stale data for a bounded time. Acceptable for social feeds, analytics, recommendation scores, notification badges. Enables async replication, higher availability, lower write latency.

Strong consistency → synchronous replication → higher write latency
Eventual consistency → async replication → potential stale reads

Step 5: Map to Architecture Constraints

From the characterised requirements, derive constraints:

If p99 read latency < 50ms AND read QPS > 10,000 → caching required
If write QPS > 5,000 → consider write buffering or async ingest
If storage > 10 TB → sharding or distributed storage required
If availability > 99.99% → no SPOF, redundancy at every layer
If strong consistency required → cannot use async replication

These constraints eliminate architecture classes and leave a narrow space of viable designs.

Key Design Decisions

AT1 — Consistency/Availability: The choice between strong and eventual consistency is the highest-leverage decision in distributed system design. Strong consistency requires coordination across replicas, which limits availability during network partitions. Eventual consistency accepts temporary inconsistency in exchange for availability and lower latency.

AT2 — Latency/Throughput: Latency and throughput trade against each other at every layer. Batching increases throughput by amortising fixed costs, but increases latency for individual requests. Caching reduces latency but adds write-path complexity and staleness risk.

AT4 — Precomputation/On-Demand: Read-heavy systems often precompute results — materialised views, cached feeds, prerendered pages. On-demand computation is simpler but cannot scale to the highest read QPS without paying the compute cost on every request.

Failure Modes in This System

FM4 — Data Consistency Failure: Choosing eventual consistency without understanding the consequences leads to anomalies users experience directly — stale inventory counts, duplicate charges, disappeared messages. Specify the acceptable staleness window before choosing eventual consistency.

FM3 — Unbounded Resource Consumption: Underestimating storage growth. Storage that looks manageable at launch becomes unmanageable in two years if the estimation was too optimistic. Build deletion policies, retention limits, and archival tiers into the design from the start.

FM6 — Hotspotting: Uniform distribution assumptions fail in practice. Users, content, and geographic load are never uniformly distributed. Estimation must account for peak-to-average ratios, not just averages. A system designed for average load fails at peak.

How It Evolves at Scale

At 10×: the database write path is the bottleneck. Sharding by user ID or content ID distributes writes. The read path moves toward dedicated read replicas. Consistency guarantees become harder to maintain across shards.

At 100×: data volume requires tiered storage — hot data in fast databases, warm data in object storage, cold data archived. The query model changes: not all historical data can be served at the same latency target as recent data.

Real-World Variants

Google’s Capacity Planning treats back-of-envelope estimation as a discipline, not an approximation. Their Site Reliability Engineering book documents the estimation process used before any major feature launch.

Amazon’s Six-Pager requires written characterisation of scale requirements before any system is designed. The document includes estimated load, growth projections, and failure scenarios — all non-functional requirements made explicit.

Stripe’s RFC Process requires that any system design document state the read and write QPS, storage requirements, and latency targets as the first section. Architecture decisions are not evaluated without those numbers.

Twitter’s Capacity Model (documented in their engineering blog) showed that the fan-out problem — a celebrity post triggering millions of feed updates — was invisible in back-of-envelope estimates that used average follower counts. The p99.9 case, not the average, drove the architecture.

Exercises