Design from requirements, not from fashionable boxes

A system design interview is not a contest to draw the most boxes. The interviewer is evaluating whether you can turn an ambiguous product into explicit constraints, choose components for reasons, and discover where the design breaks. Begin with the simplest design that satisfies the stated requirements, then evolve it only when evidence exposes a limit.

1. 01Clarify scope (3–5 minutes). Name the primary users, core actions, exclusions, and success criteria.
2. 02Rank quality goals (2–3 minutes). Discuss availability, latency, durability, consistency, privacy, and cost. Rank them; “all of them” is not a trade-off.
3. 03Estimate scale (5 minutes). Calculate peak reads and writes, stored bytes, bandwidth, object size, retention, and geographic distribution.
4. 04Write the contract (5 minutes). Define APIs or events, identifiers, idempotency behavior, pagination, and important errors.
5. 05Model the data (5 minutes). Identify entities, keys, access patterns, indexes, ownership, and consistency requirements.
6. 06Draw and trace (10–15 minutes). Narrate one write, one read, and one failure through the architecture.
7. 07Stress and evolve. Find the first bottleneck, mitigate it, and state the new cost and operational burden.

Separate functional requirements—what users can do—from non-functional requirements—how safely and quickly the system must do it. A useful requirement changes a design decision or can be verified. “Highly scalable” is not testable; “sustain 20,000 writes per second while keeping p99 latency below 200 ms” is.

Back-of-the-envelope estimates establish order of magnitude. Write units on every value, keep one significant digit, distinguish average from peak, and explain the decision the estimate informs. Precision without defensible assumptions is false confidence.

An API names the work the system promises; the data model makes its dominant access patterns efficient and its invariants enforceable. Define the contract before selecting a database brand. For each operation, write its key, query shape, result size, rate, latency goal, and consistency expectation.

Operation: getOrder(orderId)
Peak rate: 20,000 reads/second
Result size: under 20 KB
Latency objective: p99 under 80 ms
Consistency: read-your-writes for the buyer
Query shape: point lookup by primary key
Retention: seven years

1. 01Choose identifiers and define whether clients may safely retry creation with an idempotency key.
2. 02Use cursor pagination when results change while the client is paging; define the stable sort key.
3. 03Enforce uniqueness and conditional state transitions in the authoritative write, not only in application memory.
4. 04Add an index only for a named query and account for its storage and write amplification.
5. 05Identify derived copies such as caches, search indexes, and feeds; define repair when an update is missed.

A diagram becomes a design only when you can narrate state changes through it. Trace a successful write, a successful read, and one dependency failure. At each hop, state ownership, timeout, retry behavior, persistence, and the signal that proves success.

Scope the first version to creating short links, redirecting a code, optional custom aliases, expiration, and asynchronous click analytics. Redirects are public; creation is authenticated and rate-limited. The mapping must never resolve to the wrong destination, while analytics may lag.

Assume 10 million new links per month and a 100:1 redirect-to-create ratio. That is roughly 4 creates/s and 400 redirects/s on average. Designing for a 10× peak gives 40 creates/s and 4,000 redirects/s. At about 500 bytes per mapping, one year adds roughly 60 GB before indexes and replicas. This estimate does not justify sharding on day one.

1
2
3
4
5
6
7
8
9
10
11
12

POST /v1/links
Idempotency-Key: 0b8d...
Content-Type: application/json

{"url":"https://example.com/long/path","customAlias":"docs"}

201 {"code":"docs","shortUrl":"https://sho.rt/docs"}
409 when a requested custom alias already exists

GET /docs
302 Location: https://example.com/long/path
404 when absent; 410 when known but expired

Use 302 while destinations may change. Use 301 only when permanent intermediary and browser caching is intended. Store Link(code PK, destinationUrl, ownerId, createdAt, expiresAt, status) and add (ownerId, createdAt) only if owner-history queries are required.

1. 01Create: authenticate, validate URL policy, rate-limit, check the idempotency key, generate a random code, insert with a unique constraint, then populate or invalidate cache after commit.
2. 02Redirect: validate the path, check edge/service cache, read by primary key on miss, reject expired or disabled links, cache with a bounded TTL, and return the redirect.
3. 03Analytics: publish a click event after deciding the redirect. Never make analytics part of the redirect’s success path.
4. 04Hot link: serve from edge cache and coalesce misses; accept the invalidation and staleness cost.
5. 05Primary failure: fence the old writer before promoting a replica; creation may pause while cached redirects remain available.

End by restating the most important trade-off and the first production measurement you would validate. A strong answer is explicit about uncertainty: it distinguishes what the requirements proved, what the estimates assumed, and what operational evidence would trigger the next architectural change.