Ch. 19 · System Design

System Design Requirements Before Components

System Design Requirements Before Components. Learn the reasoning, a practical example, common mistakes and an interview exercise.

~2 min readbeginnerupdated Oct 3, 2026

A design starts with users, operations and quality constraints. Clarify scale and correctness before drawing infrastructure.

Before you start

You should understand API requests, storage and basic capacity estimates. Begin with a concrete user action and its correctness requirement. Draw data flow and failure boundaries before selecting infrastructure; a technology name by itself does not explain why a design meets the requirement.

The practical goal is to reason through this situation: A read-heavy catalog and a financial ledger have different consistency and recovery needs. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.

Step-by-step walkthrough

Step 1: Define core user actions

Identify the operations the system must actually support.

Step 2: Clarify correctness constraints

Ask what may be stale, lost, duplicated or unavailable.

Step 3: Estimate workload

Use explicit scale and latency assumptions before selecting components.

Worked scenario

A read-heavy catalog and a financial ledger have different consistency and recovery needs.

A catalog can serve briefly stale descriptions, while a ledger must preserve financial entries under failure. Both may have high read traffic, but that similarity does not justify identical storage and recovery rules. Write the important guarantees beside the request flow before discussing caches or replication.

Common mistake

Listing popular technologies does not explain whether requirements are met.

Verify the behavior

Trace one user action and confirm every component supports a stated requirement.

Interview exercise

Open a design interview.

Answer and reasoning

Ask about core operations, expected load, latency, availability and which data must never be lost or stale.

Continue learning

Compare the scenario with the System Design interview questions and test your understanding with the System Design MCQs. For terminology and implementation details, consult the reference material.

More in System Design

read ✓System Design · hard

System Design: Bloom Filters

Use a Bloom filter to skip lookups with a tiny memory footprint, and understand its false-positive-only guarantee.

~2 min readread →
read ✓System Design · hard

System Design: Idempotent APIs

Make retried requests safe with idempotency keys, store the result per key, and return the original response on a repeat.

~2 min readread →
esc