Design Requirements
Requirements are the highest-leverage part of a system design interview. The same product can require very different architectures depending on read/write ratio, skew, latency objective, durability, consistency, tenant isolation, geographic scope, and growth. Senior candidates do not merely ask clarifying questions; they prioritize them, propose reasonable defaults, quantify consequences, and keep a decision log as the design evolves.
How to use this chapter
- Read the mental model and mechanics without taking notes.
- Close the page and explain the topic aloud in five minutes.
- Work the quantitative example on paper.
- Answer the question ladder without revealing the answer signals.
- Complete one design drill and score yourself with the senior checklist.
Learning objectives
- Separate functional requirements, quality attributes, constraints, and out-of-scope items.
- Define SLIs/SLOs, latency percentiles, availability, durability, RTO, and RPO precisely.
- Estimate request rate, concurrency, storage, bandwidth, fan-out, and growth using transparent assumptions.
- Elicit workload shape, skew, seasonality, abuse, and failure scenarios.
- Prioritize correctness, security, privacy, compliance, operability, and cost alongside scale.
- Use requirements to drive architecture choices and explain trade-offs at senior level.
Mental model
Requirements form a constraint system. Functional requirements define what users can do. Quality attributes define how well and under what failures it must work. Business and technical constraints limit the solution space. A good interview answer turns vague adjectives—“fast,” “reliable,” “real-time,” “massive”—into metrics and user-visible semantics.
Core mechanics
Functional scope and critical journeys
Identify actors, commands, queries, and externally visible workflows. Prioritize two or three critical journeys rather than designing every feature. For a chat system, sending/receiving messages, reconnect catch-up, and conversation history may be core; typing indicators and search can be deferred.
Define acceptance semantics. Does “send succeeded” mean accepted by the gateway, durably stored, replicated, delivered to recipient devices, or read by the user? These boundaries determine APIs, queues, and acknowledgments.
SLIs, SLOs, and error budgets
An SLI is a measured indicator such as successful request ratio or p99 latency. An SLO is a target over a window, such as 99.95% of valid writes durably accepted in 30 days. An SLA is a contractual commitment and may define credits or exclusions. Avoid saying “five nines” without naming the operation, population, window, and measurement point.
Error budgets connect reliability to release velocity. A service with a 99.9% success SLO has a 0.1% error budget, but correlated user impact and long outages may matter more than a uniform fraction. Include correctness and freshness SLIs where returning stale or wrong data is worse than an explicit error.
Latency, freshness, and consistency
Specify percentile and scope: p99 server processing, p95 end-to-end mobile latency, or maximum event freshness. Average latency hides tails. “Real time” might mean under 100 ms for multiplayer input, under 5 seconds for notifications, or under 10 minutes for analytics.
Consistency is operation-specific. Ask about read-your-writes, monotonic reads, per-key ordering, uniqueness, inventory oversell, and cross-object atomicity. Many systems can use strong consistency for a small write path and eventual consistency for search, analytics, and replicated views.
Durability, RPO, and RTO
Durability is the probability that acknowledged data is not lost. RPO is the acceptable data-loss window after a disaster. RTO is the acceptable time to restore service. A backup that has never been restored is not a recovery plan.
Clarify failure scope: process, host, zone, region, operator error, malicious deletion, or dependency compromise. Replication handles some hardware failures but can propagate corruption or deletion; versioning, immutable logs, and offline backups address different threats.
Workload model and skew
Capture users, active ratio, operations per user, payload sizes, read/write ratio, object count, retention, and growth. Then ask about distribution: top creators, hot keys, viral content, regional concentration, batch imports, and synchronized clients. Averages design the wrong system when the workload is heavy-tailed.
Model steady state, expected peak, launch/incident peak, and degraded capacity. Define whether traffic can be throttled, queued, sampled, or rejected and which tenants or operations receive priority.
Security, privacy, and abuse
Requirements should include authentication, authorization granularity, tenant isolation, encryption, secret management, audit, data residency, deletion, retention, and threat model. Public APIs need rate limits, bot/abuse controls, payload limits, and fraud considerations.
Security constraints shape architecture: end-to-end encryption limits server-side search; regional residency constrains replication; per-tenant keys affect caching and storage; auditability favors immutable event records.
Operability, cost, and evolution
Define on-call expectations, observability, deployment frequency, rollback, capacity lead time, and dependency ownership. A design may meet runtime SLOs but be unacceptable if restore takes days or every schema change requires global downtime.
Cost requirements include compute, storage, requests, egress, managed-service premiums, and engineering toil. Also capture growth horizon and migration constraints: existing clients, legacy data, zero-downtime expectations, and regulatory approvals.
Decision table
| Decision | Prefer the first option when… | Prefer the second option when… | Senior caveat |
|---|---|---|---|
| Strong vs eventual consistency | Incorrect/stale decisions violate an invariant or user trust. | Temporary divergence is acceptable and buys latency/availability/scale. | Choose per operation and state the anomaly users may observe. |
| Synchronous completion vs accepted/async | The user needs the final result within the interaction budget. | Work is slow, bursty, retryable, or externally dependent. | An async API needs durable status, idempotency, cancellation, and expiry semantics. |
| Multi-region active vs regional recovery | Regional latency/continuity is a hard requirement. | RTO permits failover and consistency/simplicity dominate. | Define write ownership, conflict policy, DNS/routing behavior, and tested failover. |
| Exact data vs sampled/approximate | Financial, authorization, or correctness decisions require exactness. | Analytics or ranking can trade bounded error for cost/latency. | State confidence/error bounds and whether approximation is user-visible. |
| Retain forever vs lifecycle deletion | Legal/business value justifies cost and risk. | Privacy, regulation, and economics favor bounded retention. | Deletion must cover replicas, indexes, caches, backups, and derived data. |
| Build vs managed service | Differentiation or unusual guarantees require control and the team can operate it. | Standard capability and reduced toil are more valuable. | Model lock-in, quotas, failure modes, egress, portability, and operational expertise. |
Quantitative reasoning
Failure modes and production signals
| Failure mode | What users see | Likely cause | Mitigation / design response | Useful signals |
|---|---|---|---|---|
| Under-specified success boundary | Users think data is safe or complete when it is only queued | Ambiguous API semantics | Name acknowledgment stages and expose durable status | Stage latency, lost-after-ack audits, status transitions |
| Average-based capacity | Hot users/keys overload one shard | Ignored skew and peak distribution | Model percentiles/top-N, isolate hot keys, adaptive partitioning | Per-key/tenant load, shard max-to-mean ratio |
| Unmeasurable SLO | Teams debate whether an incident violated reliability | No SLI population or measurement point | Define valid requests, windows, probes, and ownership | SLI coverage, missing telemetry, burn rates |
| Recovery gap | Replication exists but restore/failover fails | RTO/RPO not tested | Automated restore drills, runbooks, immutable backups, game days | Backup age, restore duration, failover success |
| Abuse-driven overload | Legitimate users throttled or service cost spikes | No quotas or adversarial workload model | Identity-aware rate limits, budgets, payload caps, fraud controls | Per-principal demand, rejection reason, cost anomalies |
| Requirement drift | Architecture optimizes obsolete assumptions | No decision log or validation | Track assumptions, instrument real workload, revisit milestones | Forecast error, feature adoption, capacity variance |
Senior-level lenses
Prioritize questions by architectural leverage
Do not spend ten minutes asking low-impact details. First clarify critical journey, scale order, write/read shape, consistency/durability, latency, geography, and major failure tolerance. State a default and proceed when the interviewer has no preference.
Use a requirements matrix
Map each important operation to latency, consistency, durability, availability, and authorization needs. This prevents blanket labels such as “the system is AP” or “all data is strongly consistent.” It also reveals which paths can be cached, queued, or degraded.
Separate user promise from internal mechanism
Users care that a message is not lost and appears in order; they do not care whether the backend uses a log or table. Define the external guarantee first, then select mechanisms. This keeps the design open to migration.
Plan for correlated and operator failures
Independent-instance assumptions fail when all instances share a region, deployment, certificate, quota, or bad configuration. Include dependency and control-plane failures, accidental deletion, and rollback. Reliability targets should drive fault-domain diversity and change safety.
Cost is multidimensional
Include engineering time, operational toil, incident risk, and migration cost in addition to cloud bills. A managed database with a higher unit price may be cheaper if it avoids a specialist team; a high-egress architecture can dominate total cost despite cheap compute.
Make trade-offs reversible where possible
Prefer versioned APIs, abstraction around storage semantics, partitionable identifiers, and replayable logs when future requirements are uncertain. Do not overbuild every possibility; identify the irreversible decisions and buy optionality there.
Interview question ladder
What is the difference between a functional and a non-functional requirement?
Show strong-answer signals
Functional describes behavior/capabilities; non-functional or quality attributes describe latency, availability, security, scale, and operational constraints. Give operation-specific examples.
Define SLI, SLO, and SLA.
Show strong-answer signals
Measured indicator, internal target, and contractual commitment. Include population, window, and measurement point.
What are RPO and RTO?
Show strong-answer signals
Acceptable data-loss window and restoration time after a defined disaster. Explain that replication, backups, and failover address different failures.
How do you estimate traffic from daily active users?
Show strong-answer signals
Operations/user/day divided by seconds/day, then apply peak factor and account for skew, retries, background work, and growth.
Why is p99 latency more useful than average latency?
Show strong-answer signals
It represents tail experience and exposes queueing/stragglers; name the request population and avoid treating one percentile as the entire distribution.
What consistency questions would you ask for a social feed?
Show strong-answer signals
Read-your-writes for posts, ordering per author/conversation, deletion propagation, counter accuracy, stale ranking tolerance, and whether duplicates are acceptable.
The prompt says “design a highly available file service.” What are your first five clarifications?
Show strong-answer signals
Critical operations and success boundary; object size/workload; durability/RPO; availability/RTO and regional scope; consistency/overwrite semantics; then security/retention and scale.
How would requirements differ between a payment ledger and a view counter?
Show strong-answer signals
Ledger needs strong invariants, audit, idempotency, durable ordered writes, precise recovery; counter may accept approximation, batching, sharding, and eventual convergence. Still define abuse and reset semantics.
A PM asks for 99.999% availability and zero data loss. How do you respond?
Show strong-answer signals
Clarify operation/failure/window, quantify cost/downtime, identify correlated and regional failures, distinguish durability from availability, propose tiers, and require tested recovery plus business justification.
How do you turn a vague “real-time analytics” request into design inputs?
Show strong-answer signals
Freshness target, query latency, dimensions/cardinality, ingest rate/size, exactness, retention, late events, replay, audience concurrency, and failure/degradation behavior.
Create a requirement strategy for migrating a regulated product from one region to active-active.
Show strong-answer signals
Data residency, conflict/invariant analysis, per-operation consistency, RPO/RTO, audit, key management, dependency mapping, staged traffic, reconciliation, rollback, and evidence for regulators.
Your launch forecast could be wrong by 100×. How do you design requirements and rollout?
Show strong-answer signals
Range scenarios, hard quotas and admission, queueable/degradable features, load tests, regional/tenant rollout, autoscaling limits, cost guardrails, kill switches, and live assumption validation.
Design drills
Write a one-page requirement sheet for a collaborative document editor. Include operation-specific latency, consistency, offline behavior, document size, active collaborators, history retention, permissions, and regional failure behavior.
What the interviewer is testing
Turning product language into measurable semantics and identifying which guarantees conflict.
Assume 50M DAU, 30 viewed clips/user/day, 2 uploads per 100 users/day, and 8 MiB average clip after encoding. Estimate request rate, origin storage growth, CDN egress, and the variables most likely to dominate cost.
What the interviewer is testing
Transparent estimation, peak/skew, replication and derivative assets, and sensitivity analysis.
Define SLIs and SLOs for browse, add-to-cart, place-order, payment, and fulfillment events. Include a degraded mode and an error-budget policy.
What the interviewer is testing
Operation-specific reliability, correctness versus availability, and measurable user journeys.
Common weak answers and how to improve them
“We need low latency.”
Show the stronger answer
Specify percentile, operation, geography, load condition, and end-to-end versus server scope.
“Assume 10× peak.”
Show the stronger answer
Explain why, test sensitivity, and ask about launches, diurnal patterns, retries, and hot users.
“No data loss.”
Show the stronger answer
Name the acknowledged boundary, disaster class, RPO, backups, and restore validation.
“Strong consistency everywhere.”
Show the stronger answer
Map consistency needs per operation and explain latency, availability, and implementation cost.
“Security is out of scope.”
Show the stronger answer
At minimum cover identity, authorization, tenant isolation, encryption, abuse, and audit because they shape architecture.