Lesson 5 · Scaling and Trade-offs

Design Requirements & Estimating Resource Needs

Turning vague product goals into concrete, quantifiable engineering constraints.

System design begins with translating vague product goals into numerical boundaries. You cannot design for "high scale" or "low latency" until those terms are defined as concrete targets — a specific RPS figure, a specific latency percentile, a specific number of nines.

This lesson covers two things: how to split requirements into functional and non-functional buckets, and how to turn a handful of business projections into Back-of-the-Envelope (BOTE) numbers for throughput, storage, and bandwidth — the numbers that tell you whether your architecture is even feasible.

Defining Requirements

Functional vs. Non-Functional

Every requirement you gather falls into one of two buckets. Confusing the two is a common source of designs that satisfy the product spec but fail under real load.

Functional

Defines what the system does — the features and capabilities visible to the user or another service.

Example: "Users can upload photos." "Users can search for a driver nearby."
Non-Functional (NFR)

Defines how the system performs — the quality attributes that determine whether the functional behavior holds up under real-world conditions.

Example: "Photo retrieval must occur within 200ms at the 99th percentile."
When establishing NFRs, focus on three specific levers: traffic patterns, data retention, and availability targets.

Three Levers

NFRsWhat to Interrogate First

Traffic PatternsShape

Is the load read-heavy, like a news feed serving far more views than posts, or write-heavy, like a logging or telemetry pipeline? This determines whether you optimize for caching and read replicas or for write throughput and ingestion buffering.

Data RetentionVolume

How much data must be stored, and for how long? A chat app retaining messages forever has fundamentally different storage economics than one that purges after 30 days.

Availability TargetsUptime

What is the maximum acceptable downtime? A target of 99.9% versus 99.99% changes your redundancy strategy, deployment process, and infrastructure cost by orders of magnitude.

Back-of-the-Envelope

The Rule of 86,400

There are 86,400 seconds in a day. Divide total daily requests by that constant and you get average requests per second — the starting point for every capacity estimate.

100M DAU × 10 requests/day

DAU
100,000,000
→
Requests / user / day
10
→
Daily requests
1,000,000,000
→
÷ seconds/day
86,400
→
Average RPS
≈ 11,574
Always design for peak load, not average. Diurnal traffic patterns commonly push peak to 3-5x the average — so the ~11,574 average RPS above should translate to provisioning for roughly ~40,000 RPS at the top of the curve.

Back-of-the-Envelope

Storage Capacity Projection

Storage calculations rely on the size of a single record multiplied by the frequency of creation. If a user creates one 50KB post daily, the numbers compound fast.

100M users × 50KB post/day

Daily active writers
100,000,000
→
Avg. record size
50 KB
→
Daily storage
5 TB / day
→
× 365 days
×365
→
Annual storage
≈ 1.8 PB / year
This magnitude instantly informs the design. ~1.8PB of growth per year dictates that you cannot store everything on a single server — you will need a distributed storage strategy and a partitioning plan.

Trade-offs

Raw Size Is Never Final Size

When estimating, you must account for overhead. Indexing, replication, and metadata add 20% to 50% on top of raw data size. A 1.8PB/year projection can realistically land closer to 2.2-2.7PB/year once these are factored in — and that gap is exactly the kind of number that changes a budget conversation.

Putting It Together

From Product Goal to Architecture Decision

Define Product Goal
↓
Identify Functional Requirements
↓
Establish NFRs — Latency, Availability, Throughput
↓
Calculate Throughput
Peak RPS
↓
Load > single instance?
Yes ↓
Plan Horizontal Scaling
Calculate Storage
Growth Rate
↓
Data > single disk/node?
Yes ↓
Plan Partitioning Strategy
Every design decision downstream — horizontal scaling, partitioning, caching — traces back to whether these BOTE numbers exceed what a single instance or single node can handle.

Back-of-the-Envelope

Bandwidth: The Hidden Bottleneck

Beyond raw CPU and storage, bandwidth is often overlooked. Response payloads must physically move across the network, and that cost scales linearly with both request rate and payload size.

Required bandwidth
40,000 RPS × 100KB
≈ 4 GB/s
10Gbps link capacity
10 Gbps
≈ 1.25 GB/s
At 4GB/s of required throughput, you’d need at least four 10Gbps links saturated at 80% just to serve this traffic — before accounting for inter-service communication. When these numbers exceed your constraints, the fix is architectural: push toward caching and edge computing rather than scaling raw network capacity linearly.

Summary

Numbers Define the Boundaries

Resource estimation transforms vague ambitions into architectural requirements. By calculating peak RPS, storage volume, and bandwidth consumption, you define the physical boundaries your system must overcome — boundaries that will directly guide your decisions on data partitioning and communication protocols in the lessons ahead.

Quiz Review

Check your understanding

Question 1 of 8

What is the difference between functional and non-functional requirements?

  • ✓Functional requirements define what the system does (e.g., "users can upload photos"). Non-functional requirements (NFRs) define how the system performs — latency, throughput, availability.