System Design Requirements and Constraints: Ask Better Questions Before You Draw

Scenario context

In system design interviews, weak answers fail early because requirements are fuzzy. Strong answers start by turning vague prompts into explicit functional scope, measurable non-functional targets, and clear trade-off boundaries before any architecture diagram appears.

TLDR: If you clarify requirements well, the architecture almost chooses itself.

flowchart TD
    A[Vague interview prompt] --> B[Clarify functional scope]
    B --> C[Capture non-functional targets]
    C --> D[Set constraints and assumptions]
    D --> E[Define out-of-scope boundaries]
    E --> F[Map constraints to components]
    F --> G[Present architecture with trade-offs]

Observable outcome: Functional requirements define what the system does — user actions, core operations, and API boundaries; non-functional requirements define how well it must do it — latency targets, availability SLOs, and consistency le…

Stage 5 — Real-World Applications: Notification, Feed, and Checkout Systems

• The same requirement framework applies across very different domains.
• Notification platform: - Functional: send notification, view delivery status.
• • Non-functional: near-real-time delivery for push, eventual for email.
• • Constraints: provider rate limits, regional SMS regulations.

Observable outcome: - Constraints: provider rate limits, regional SMS regulations.

Stage 6 — Practical Example: Requirement Breakdown for "Design a Chat System"

• Suppose the interviewer says: "Design WhatsApp." A structured response starts with narrowing: - Phase 1: one-to-one messaging only.
• • Exclude group chat, media compression, and end-to-end encryption details from MVP.
• Then define measurable assumptions: Now architecture decisions follow naturally: 1.
• Per-conversation ordering requirement - partition messages by conversation ID.

Observable outcome: Per-conversation ordering requirement - partition messages by conversation ID.

End-to-end outcome

After working through the stages, you should be able to explain:

• • Requirements are architecture inputs, not interview formalities.
• • Functional, non-functional, and business constraints should be separated explicitly.

Alternatives considered

Decision Guide: Which Requirement Style Fits the Interview Prompt?

This decision table helps you adapt your questioning style without sounding scripted.

Failure and degraded modes

Trade-offs & Failure Modes: What Goes Wrong When Requirements Are Weak

• Detection: A strong candidate explicitly narrates these failure modes and shows how requirement discipline prevents them.
• User or operator impact: A strong candidate explicitly narrates these failure modes and shows how requirement discipline prevents them.