System Design Interviews: Flow, Patterns & Templates

System Design Interviews

System design interviews evaluate how you reason about building scalable, reliable systems — gathering requirements, weighing tradeoffs, modeling data, designing APIs, and addressing operational concerns. There's rarely one right answer; what's assessed is whether you can drive a structured conversation and justify your choices.

The winning approach is disciplined: clarify before designing, start simple and high-level, then iterate by naming bottlenecks and failure modes and reaching for the right tool (cache, queue, replica, shard) with its tradeoff stated out loud.

TL;DR

Clarify requirements first (functional + non-functional).
Start with a simple high-level design, then iterate.
Identify bottlenecks and failure modes explicitly.
Reach for caching, queues, sharding, consistency, observability — and name the tradeoff.

Quick Example

A correct cache-aside read path is often enough — say the tradeoffs out loud:

A Strong Interview Flow

Clarify requirements — what are we building, for whom, at what scale (QPS, storage, growth), with what success metrics (latency, availability)?
Define core entities and APIs — primary resources, read/write patterns. See REST API Design.
High-level architecture — clients, API layer, data stores, caches, async processing.
Deep dives — data model, consistency, scaling, reliability, observability.
Wrap up — summarize tradeoffs, note risks and mitigations.

A Reusable Template

When stuck, draw this and customize — then mark what's synchronous vs async, and where you enforce auth, rate limits, and retries:

High-Signal Patterns

These show up in real systems and demonstrate tradeoff thinking:

See Message Queues.

Non-Functional Concerns

Scalability — horizontal scaling, stateless services, load balancing. See Scalability Patterns.
Reliability — graceful degradation, retries + timeouts, rate limiting, circuit breakers.
Performance — caching, indexing, avoiding hot paths. See Caching.
Data consistency — strong vs eventual, idempotency. See Event-Driven Architecture.

Data Model & Access Patterns

Estimation & Building Blocks

Be ready for back-of-the-napkin estimates — requests/sec, storage size, bandwidth. You don't need exact numbers, just order-of-magnitude reasoning.

Common building blocks to compose from: load balancer, API gateway, relational DB, cache, queue/stream, object storage, search index, observability stack.

Common Deep-Dive Questions

Best Practices

Requirements before architecture — never start drawing boxes cold.
Start simple, then justify each added component with a concrete need.
Name tradeoffs out loud — every choice costs something.
Address failure modes — interviewers care about what breaks and how you contain it.
Don't reach for microservices without a reason.

Common Mistakes

Jumping to details before clarifying

"Microservices everywhere"

FAQ

How do I structure my time in a 45-minute system design interview?

Roughly: ~5 min clarifying requirements and scale, ~5 min defining entities/APIs, ~10 min on a high-level design, ~15–20 min on deep dives the interviewer steers toward, and a few minutes to wrap up tradeoffs and risks. The biggest mistake is skipping clarification and over-investing in one component while ignoring the rest — keep the whole system in view, then go deep where prompted.

How precise do my capacity estimates need to be?

Not very — interviewers want to see you reason about orders of magnitude, not exact figures. Estimate requests/sec from users × actions, storage from records × size × retention, and bandwidth from payload × QPS. Round aggressively and state assumptions. The point is to justify decisions ("at ~10k QPS we'll need caching and read replicas"), not to be arithmetically perfect.

When should I introduce a queue, cache, or shard?

Introduce each in response to a named problem, not preemptively. A cache when reads are hot and repeatable; a queue when work is slow/bursty and can be async; read replicas when reads outpace a single primary; sharding only when a single database can't hold the write volume or data size. Always pair the addition with its tradeoff (invalidation, eventual consistency, cross-shard queries).

What separates a strong answer from a weak one?

Tradeoff awareness and failure thinking. Weak answers list technologies; strong answers explain why each choice fits the requirements and what it costs, then proactively address what breaks (dependency failures, hot keys, consistency) and how to mitigate it (timeouts, retries, circuit breakers, idempotency). Driving the conversation structurally — requirements → design → deep dives → tradeoffs — is itself a strong signal.