Functional vs Non-Functional Requirements

easy

All

FrameworkRequirements

Requirements gathering is the most consequential 5 minutes of a system design interview — and the most consequential first hour of any real system design. Weak interviews fail here, not at the architecture step.

Key Concepts

*1. Functional requirements — what does the system do. Top 3-5 user stories in plain language. Inputs and outputs. Integration points with other systems. List what's out of scope explicitly* — search, DMs, monetization, recommendations all sound like 'Twitter' but you can't design them all in 45 minutes. Bounding reduces the surface to defend and signals discipline.

2. Non-functional requirements — what properties must it have. Quantified. Not 'highly available' but '99.99% = 52 min downtime/yr'. Not 'low latency' but 'p99 < 200 ms on feed load'. Scale (MAU, DAU, QPS, data volume). Latency (per operation). Availability (per SLO). Consistency (per data class). Durability (RPO, RTO). Geographic. Compliance (PII, GDPR, PCI, HIPAA, residency).

2. Non-functional requirements — what properties must it have.

3. The dialog is more important than the list. Ask: 'What's our SLA?'; 'How fresh must this be?'; 'Single region or global?'. The interviewer's answers ('99.95%, p99 < 300 ms, US + EU, GDPR-compliant') constrain the design directly. They also catch over-engineering (no, you don't need Spanner — single-region Postgres is fine) and under-engineering (yes, the home page must be fast under cache miss).

3. The dialog is more important than the list.

4. Refer back throughout. Write requirements on the whiteboard. Refer back: 'We chose async replication because the requirement said RPO of 5 minutes is acceptable.' This grounds every decision in stated constraints and prevents drift.

4. Refer back throughout.

5. Connect requirements to architecture. '99.95% uptime' → multi-AZ minimum, failover automation. 'p99 < 200 ms' → no cross-region calls in hot path. 'Strong consistency on orders' → Postgres or NewSQL, not Cassandra default. 'Multi-region writes' → multi-leader with conflict resolution. 'GDPR' → per-user deletion, per-region storage, consent management. Common mistakes: skipping this phase, vague non-functional ('scalable'), ignoring compliance, designing for today only.

5. Connect requirements to architecture.

Functional checklist

Who are the users? (consumer, internal, B2B, mixed)
Top 3-5 user stories.
Inputs and outputs of the system.
What is explicitly OUT of scope?
Are there roles / permissions?
Existing systems to integrate with?
What does success look like (e.g., a transaction completes; a user can log in)?
Edge cases to handle (abuse, error recovery, partial failures)?

Non-functional checklist

Scale:
• Users — MAU, DAU.
• QPS — read/write, average + peak.
• Data volume — current and growth rate.

Latency (with numbers):
• p50, p99 for the hot path.
• Different SLAs for different operations.

Availability:
• 99.9% (8.76h/yr), 99.99 (52 min/yr), 99.999 (5 min/yr).
• Different SLOs for different services.

Consistency:
• Strong, eventual, causal — per data class.
• Read-your-writes required?

Durability:
• RPO (Recovery Point Objective): how much data loss is acceptable?
• RTO (Recovery Time Objective): how fast must we recover?

Geographic:
• Single region, multi-region, edge?
• Multi-region active-active or active-passive?

Compliance:
• PII, GDPR, CCPA, PCI, HIPAA, SOC 2.
• Regional data residency.
• Audit log retention.

Cost: ceiling / SLO budget.

Observability: metrics, traces, logs, on-call expectations.

Time-to-market: greenfield or evolving system?

Example dialog

Q (interviewer): Design a ride-sharing app.
You:
- Riders, drivers, or both? Both.
- Geographic scope? Single city first, multi-region later.
- Scale? Assume 10M riders, 1M drivers, peak 1M req/min.
- Latency? Driver dispatch < 5s end-to-end.
- Availability? 99.95%.
- Consistency? Trip state strong; location data eventual.
- Out of scope: detailed pricing surge model, payments, fraud detection (separate systems).
- Compliance: trip history retained 7 years.
- Cost: stay within company existing cloud footprint.

Tying requirements to decisions

'99.95% uptime' → multi-AZ deployment minimum; failover automation; observability investment.

'p99 < 200ms' → can't rely on cross-region calls; need region-local caches; bounded model size for ML.

'Strong consistency on orders' → Postgres or NewSQL; not Cassandra default.

'Multi-region, low write latency' → multi-leader with CRDTs or careful conflict resolution.

'GDPR' → per-user data deletion path; per-region storage; consent management.

Common mistakes

Skipping the phase entirely.

Listing 'highly available, scalable, performant' without numbers.

Not bounding scope — trying to design everything Twitter does in 45 minutes.

Treating compliance as an afterthought — it's an architectural constraint.

Designing for today's scale only; ignoring 3-year growth.

Ignoring operability and observability.