Requirements Gathering

Pick a product, select requirements, and watch the architecture evolve live. Every requirement you add changes the infrastructure — that's the point.

Goal: See how requirements directly shape architecture — each choice you make adds or removes infrastructure.Try: Pick a product (e.g. YouTube), then toggle Non-Functional requirements one at a time and watch the architecture canvas evolve.

Step 1 — Pick a product

Requirements depend on what you're building.

2B+ users · Read-heavy, large payloads · Massive video streaming with global delivery needs.

Step 2 — Choose requirements

Toggle on/off — the architecture updates live.

Step 3 — Architecture

Hover any node to understand its role.

Live
ClientCDNLoad BalancerApp ServerCache (Redis)DatabaseRead ReplicaObject StorageMsg QueueSearch Engine

System metrics

Response Time

20ms

Availability

97.5%

Est. Cost

$164/mo

Complexity

Moderate

Step 4 — Design insights

CDN introduced — static content cached at edge nodes. Latency drops for distant users.
Redis cache added — repeated reads skip the database entirely, cutting response time.
Load Balancer in place — traffic spreads across instances, single points of failure removed.
Read Replica added — read queries routed away from the primary, increasing read throughput.
Message Queue inserted — producers and consumers decouple; bursts buffer instead of dropping.
Object Storage added — large files stored outside the database, keeping DB lean.
Search Engine added — full-text queries handled by a dedicated index, not the primary DB.

Mini Challenges

Can you build an architecture that satisfies each goal?

< 120ms at global scale

Add CDN + cache so response time drops below 120ms.

99.9%+ availability

Reach 99.9% availability with at least a read replica.

Media upload pipeline

Upload files without blocking the app server (object storage + queue).

Capacity Estimation

Why this exists

Requirements gathering exists because architecture is a response to constraints, not a blank-canvas exercise. Functional requirements tell you what the system must do. Non-functional requirements tell you how well it must do it under real load, latency, reliability, and cost limits.

Functional vs non-functional

Functional requirements define user-visible behavior. Non-functional requirements define throughput, latency, durability, consistency, availability, and budget.

Scope is an engineering tool

Explicitly saying what you are not building prevents over-design. Good scope cuts away features that would otherwise distort the system.

Requirements drive trade-offs

A low-latency read-heavy system wants very different infrastructure than a write-heavy financial ledger. The architecture follows the constraints.

Key takeaways

  • Start by clarifying users, traffic, reads vs writes, and failure tolerance.
  • Non-functional requirements are what force real architectural trade-offs.
  • Undefined scope produces vague systems and vague interviews.
  • If you cannot state the requirements cleanly, the rest of the design will drift.