Functional vs Non-Functional Requirements Lab (Interactive)
Drag DAU, reads/writes, and availability targets to derive QPS, storage, servers, and downtime budgets. Turn vague product goals into measurable functional and non-functional requirements, then run back-of-envelope capacity planning live.
Requirements & Capacity Planning Lab
Turn functional scale numbers into QPS, storage, servers, and downtime budgets before drawing boxes.
Non-Functional Inputs
Read:Write ratio is 50:1 — add read replicas and edge caching for the read tier.
Write volume fits a single primary; a queue is optional for durability bursts.
5-year raw storage exceeds 1 TB (51.0k GB) — plan sharding and tiered cold storage now.
How It Works Under the Hood
System design starts with requirements, not boxes. Functional requirements define what the system does; non-functional requirements (latency, throughput, availability, durability) define whether it survives under load. This lab converts DAU, per-user actions, record sizes, and burst factors into average and peak QPS, daily storage, egress bandwidth, and minimum server counts, while the nines selector computes the yearly downtime budget your SLA implicitly buys. Read:write ratios drive replica decisions; peak writes drive queue decisions.
Core Architectural Principles
- QPS derivation: users × actions ÷ 86,400 seconds, then ×3 burst factor for peak sizing.
- SLA hierarchy: SLI is measured, SLO is the internal target, SLA is the customer contract with penalties.
- Nines math: 99.99% availability permits ~52.6 minutes of downtime per year (525,600 × 0.0001).
Open every interview by stating FRs and NFRs explicitly: "Assuming 100M DAU, 10 reads and 1 write per user per day." Then derive read/write QPS, the ratio, and storage projections out loud — interviewers score back-of-envelope fluency heavily, and stating SLA vs SLO differences signals seniority.
Over-specifying requirements early paralyzes iteration, but omitting them guarantees a bottleneck discovered only in production.