New feature: AI Job Search! Try it now

Kairo logo

Technical Interviews

System Design Interview Framework Guide: Architecture, Trade-offs, and Structure

David Vance

David Vance

@kairo_copilot

System Design Interview Framework Guide: Architecture, Trade-offs, and Structure

System design interviews have become the defining evaluation format for senior software engineers, staff engineers, and engineering managers at most major technology companies. Unlike coding rounds with verifiable correct answers, system design interviews are open-ended by design — they evaluate your ability to think through ambiguity, make principled trade-off decisions, and communicate architectural reasoning under time pressure.

Most candidates fail system design interviews not because they lack technical knowledge, but because they lack a consistent approach to framing, scoping, and structuring their thinking.

What Interviewers Are Actually Evaluating

Before the framework, understand the rubric. System design interviewers typically score across these dimensions:

Clarification and scoping: Does the candidate ask the right questions before designing? Do they define success criteria?

Scale intuition: Does the candidate understand order-of-magnitude estimates and their implications?

Component selection and justification: Can the candidate identify the right building blocks and explain why they chose them over alternatives?

Trade-off reasoning: Does the candidate articulate the trade-offs of their choices? Do they acknowledge what they're sacrificing?

Failure mode handling: Does the candidate proactively address what happens when things go wrong?

Communication: Can the candidate guide the conversation, draw clearly, and explain decisions without being asked to explain everything?

A candidate who dives into technical details without scoping the problem, or who proposes solutions without justifying them, scores poorly regardless of technical accuracy.

The Framework: Six Stages in 45 Minutes

Stage 1: Requirements Clarification (5 minutes)

Never design before you scope. The first five minutes are for questions that determine what you're actually building.

Functional requirements — What does the system do?

  • "Are we building the full product or a specific feature?"
  • "Who are the primary users and how do they interact with the system?"
  • "What are the top 3 user actions?"

Non-functional requirements — What properties must the system have?

  • "What's the expected scale — users, requests per second, data volume?"
  • "What are the latency requirements?"
  • "What's more important: consistency or availability?"
  • "What regions do we need to support?"

Out of scope — Define what you're not building explicitly.

  • "I'll assume authentication is handled by an existing auth service."
  • "I'll treat the payment system as a black box for this design."

Stating what's out of scope is as important as defining what's in scope. It signals prioritization judgment.

Stage 2: Capacity Estimation (5 minutes)

Back-of-envelope estimation grounds your design in reality and signals systems-scale thinking.

A useful structure:

  1. Users: Daily active users (DAU), requests per user per day
  2. QPS: (DAU x requests/day) / 86,400 seconds
  3. Storage: Data per write x writes per day x retention period
  4. Bandwidth: Data per request x QPS

Example for a URL shortening service:

100M DAU, 10 reads per user = 1B reads/day
1B reads / 86,400 = roughly 11,500 QPS reads
100:1 read/write ratio → roughly 115 QPS writes
Average URL = 100 bytes, 10M new URLs/year → roughly 1GB/year storage

These numbers inform decisions: 11,500 QPS reads suggests caching is essential; 115 QPS writes are manageable with a single primary database.

Don't over-invest in precision. Interviewers want reasonable order-of-magnitude estimates, not engineering-grade calculations.

Stage 3: High-Level Architecture (10 minutes)

Draw the system at a bird's-eye level before going deep anywhere. This prevents getting stuck in one component while neglecting the overall design.

Standard components to consider:

  • Client layer: Web, mobile, external API consumers
  • Load balancer / API gateway: Entry point, routing, rate limiting
  • Application servers: Stateless compute layer
  • Caching layer: Redis, Memcached for hot data
  • Database(s): SQL vs. NoSQL, primary vs. replica
  • Message queue: Kafka, SQS for async processing
  • CDN: Static assets, edge caching
  • Storage: Object store (S3-equivalent) for blobs

Sketch this visually as you talk. A diagram helps both you and the interviewer track the design.

Stage 4: Deep Dive on Core Components (15 minutes)

After the high-level diagram, ask the interviewer: "Which area would you like to go deeper on?" This shows you can navigate the conversation collaboratively and ensures you spend time on what the interviewer actually cares about.

Common deep dive areas include database design, API design, caching strategy, message queue design, and data consistency models.

For each deep dive, apply the pattern: propose → justify → acknowledge trade-offs.

[WEAK]  "I'd use Cassandra for the database."

[STRONG] "I'd use Cassandra for the user activity data because we need horizontal 
          scalability and the access pattern is primarily key-value lookups by user ID. 
          The trade-off is that Cassandra's eventual consistency model means we might 
          show a slightly stale view of activity for a few hundred milliseconds — 
          acceptable for this use case, but not for financial transactions."

Stage 5: Addressing Failure Modes (8 minutes)

Interviewers evaluating senior candidates specifically probe failure handling. Raise it proactively rather than waiting to be asked.

Key failure modes to address:

Single points of failure: Where is there no redundancy? How do you add it?

Database failure: Primary goes down — what's the failover strategy? Is there data loss risk?

Cache failure: What happens when Redis goes down? Does your system degrade gracefully?

Message queue backup: What happens if the queue grows faster than consumers process? Dead-letter queues?

Network partition (CAP theorem): When the network partitions, what does your system prioritize — consistency or availability? Why?

Hot spots: Specific users, keys, or partitions receiving disproportionate traffic?

Addressing these signals architectural maturity — you've moved beyond happy-path thinking to adversarial, production-grade reasoning.

Stage 6: Scaling Discussion (5 minutes)

Close with how your design evolves from 1,000 to 1M to 100M users.

Common scaling patterns:

  • Horizontal scaling: Stateless compute nodes behind a load balancer
  • Database sharding: Partition by user ID or geographic region
  • Read replicas: Offload reads from primary
  • Geographic distribution: Multi-region with data locality
  • CDN expansion: Edge caches closer to users globally

Common System Design Problems and Key Insights

URL Shortener: Core challenge — generating unique short codes at scale. Key decision — Base62 vs. MD5 truncation, DB vs. in-memory lookup. Trade-off — consistency guarantees on uniqueness vs. write throughput.

Chat System: Core challenge — message delivery guarantees, online/offline state, group fan-out. Key decision — WebSockets vs. long polling. Trade-off — at-least-once delivery (potential duplicates) vs. exactly-once (expensive).

Social Feed: Core challenge — fan-out on write vs. fan-out on read for high-follower accounts. Key decision — push model (write to each follower's timeline), pull model (aggregate at read time), or hybrid. Trade-off — write amplification vs. read latency.

Distributed Cache: Core challenge — consistent hashing for node distribution, cache eviction policies. Key decision — LRU vs. LFU eviction, TTL management. Trade-off — memory cost vs. cache hit rate vs. consistency.

Communication Principles

Think out loud. Silence is the enemy. The interviewer wants to follow your reasoning, not just see the output.

Check in frequently. "Does this level of detail on caching make sense, or should I move to the database design?"

Name the trade-offs explicitly. "The advantage of this approach is X. The disadvantage is Y. Given the requirements, I'd prioritize X."

Use concrete numbers. "The load balancer needs to handle roughly 12,000 requests per second based on our estimates" is more credible than "a lot of requests."

Acknowledge what you don't know. Intellectual honesty scores better than confident fabrication.

A system design interview is a 45-minute collaboration, not a monologue. The framework — requirements, estimation, high-level design, deep dives, failure modes, scaling — gives you a structure that produces complete answers, surfaces the right trade-offs, and keeps the conversation moving. Technical knowledge matters. The framework makes it visible.

Master High-Concurrency System Design Architecture

Elevate your technical communication and trade-off justification in Senior and Staff architecture panels:

See all posts