System design interview
what they actually score
Most candidates prepare by memorizing system architectures. Interviewers care about whether you can scope requirements, identify bottlenecks, and communicate trade-offs. Different skills. Here's what they're actually evaluating — and how to prepare for it.
The 6 dimensions interviewers score
Most interviewers use a rubric. Here's what's actually on it — and the most common failure mode at each.
Problem scoping & requirements
High signalWhat they're looking for
Do you ask clarifying questions before diving in? Most candidates skip this and design the wrong system. Interviewers want to see you define functional vs. non-functional requirements, establish scale (DAU, QPS, storage), and explicitly agree on scope before drawing a single box.
Most common fail
Jumping straight to components without asking about scale, feature boundaries, or consistency requirements. You then spend 30 minutes designing something that doesn't match what they asked for.
How Zari coaches this
Zari drills the requirements phase — practicing opening frameworks that surface the 5–7 questions you must ask before any system design begins.
High-level architecture
High signalWhat they're looking for
A clear component diagram: clients, load balancers, services, databases, caches, queues, CDN. Not perfect — correct direction. Senior engineers draw clean boundaries between services, state what each owns, and explain why services are split the way they are.
Most common fail
A single monolith with arrows pointing everywhere. Or over-engineering with microservices when the scale doesn't call for it. Interviewers evaluate whether your architecture matches the stated scale.
How Zari coaches this
Practice translating scale requirements into architecture decisions. Zari asks follow-up questions that surface whether your architecture matches your requirements.
Data modeling & storage
High signalWhat they're looking for
Schema design, access patterns, database selection rationale. Should this be SQL or NoSQL — and why? How do you store user events at 10M/day? What does the entity-relationship model look like? Senior candidates name their tables, define primary keys, and explain indexing strategy.
Most common fail
Vague 'just use a database' answers without naming the engine, explaining schema, or justifying the choice against alternatives. Interviewers flag this as operating below senior level.
How Zari coaches this
Zari covers the SQL vs NoSQL decision matrix and schema design patterns for common system types — feeds, messaging, analytics, and user profiles.
Scalability & bottlenecks
High signalWhat they're looking for
Where does the system break at 10x current load? Proactively identifying bottlenecks — write throughput, single-point-of-failure services, hot partitions — and proposing solutions. Caching strategy, horizontal scaling, database sharding, read replicas.
Most common fail
Designing the happy path without discussing failure modes or scale limits. The interviewer will push: 'This has 100M users — now what?' Candidates who haven't pre-thought this visibly struggle.
How Zari coaches this
Zari runs scale-up scenarios — given a baseline design, coaches you through identifying and resolving the next three bottlenecks.
API design
Medium signalWhat they're looking for
REST vs. GraphQL rationale, endpoint definitions, request/response shape, pagination strategy, authentication mechanism. Senior candidates can articulate why their API contract is designed the way it is — not just list endpoints.
Most common fail
Listing endpoints without specifying methods, response shape, or pagination. Or defaulting to REST without considering whether the client's access patterns favor GraphQL.
How Zari coaches this
Zari covers API design trade-offs and how to communicate API decisions clearly in a 45-minute interview window.
Trade-off communication
High signalWhat they're looking for
The ability to name a trade-off, explain both sides, and make a reasoned choice — rather than presenting your design as the only valid answer. Eventual vs. strong consistency, latency vs. throughput, normalization vs. denormalization. Senior engineers make these choices explicitly.
Most common fail
Presenting one approach as if it's obviously correct. Interviewers probe trade-offs specifically — if you don't surface them, they will, and you'll look like you hadn't considered them.
How Zari coaches this
Zari coaches the trade-off framing habit: for every major decision, articulate what you're optimizing for and what you're giving up.
The 5-step framework for any system design question
A repeatable structure that works for 90% of system design prompts — and prevents the most common failure modes.
Clarify requirements (5 min)
- Who are the users? What are they doing?
- Define scale: daily active users, peak QPS, data volume per day
- Functional requirements: what the system must do
- Non-functional requirements: latency SLA, consistency, availability
- Explicitly scope what's in and out for this interview
Why it matters
Requirements define everything downstream. A messaging system optimized for 1K users looks nothing like one optimized for 1B users. Get this wrong and you design the wrong system.
Estimate scale (3 min)
- DAU × actions per user = daily writes
- Reads are usually 10–100× writes — establish read/write ratio
- Storage: daily data size × retention period
- Bandwidth: data transferred in/out per second at peak
- State your assumptions out loud and write numbers on the whiteboard
Why it matters
Scale numbers determine architecture. 1K QPS vs. 1M QPS requires completely different storage engines, caching strategies, and service topology. Most candidates skip this and their architecture has no justification.
High-level design (10 min)
- Draw the major components: client, load balancer, services, DB, cache, queue
- Name each component and state what it owns
- Explain the data flow through the system end-to-end
- Keep it simple — don't over-engineer before you've agreed on the shape
- Get explicit signal from the interviewer before going deep
Why it matters
The HLD is your contract with the interviewer. It sets what you'll deep-dive next and ensures you're both looking at the same system.
Deep dive: 2–3 components (15 min)
- Pick the most interesting or risky components to go deep on
- Data schema: tables, keys, indices
- Caching layer: what goes in cache, TTL, eviction policy, invalidation
- Asynchronous processing: queues, consumers, retry/dead-letter strategy
- Database choice: SQL vs. NoSQL — justified by access patterns
Why it matters
This is where you demonstrate senior-level thinking. Interviewers evaluate whether your depth matches your claimed experience. Vague answers here are the most common senior-level failure mode.
Scale & edge cases (7 min)
- Identify the top 3 bottlenecks in your current design
- Propose horizontal scaling, sharding, or read replicas where appropriate
- Discuss failure modes: what happens when service X goes down?
- State consistency/availability trade-off for each major component
- Summarize what you'd do with more time
Why it matters
Senior candidates proactively scale their designs. If you wait for the interviewer to ask 'but what about scale?' you've missed the signal they were waiting for.
4 systems you'll almost certainly be asked to design
The key decisions, storage choices, and senior-level signals for each common prompt.
Design: URL Shortener
Key decisions
- Read-heavy (10:1 read/write ratio)
- Hash generation strategy (MD5 prefix vs. counter)
- Redirect type: 301 vs. 302
- Analytics: sync vs. async event tracking
Storage choice
SQL or wide-column (Cassandra) for URL mappings; Cache heavily on read path
Senior signals
- Custom base-62 encoding for shorter URLs
- Bloom filter to detect hash collisions before DB lookup
- Geographically distributed caching
Design: Design Twitter / News Feed
Key decisions
- Fan-out on write vs. fan-out on read
- Timeline storage: precomputed vs. computed at request time
- Celebrity problem: users with 10M followers
Storage choice
User graph in Redis; Posts in SQL; Feed in Redis sorted sets or precomputed in Cassandra
Senior signals
- Hybrid fan-out: precompute for non-celebrity, merge at read time for celebrities
- Sharding strategy for hot users
- CDN for media assets
Design: Design a Chat System
Key decisions
- Connection: WebSocket vs. long polling vs. SSE
- Message delivery: at-least-once vs. exactly-once
- Online presence detection
Storage choice
Message history in Cassandra (append-optimized); Session state in Redis; Fan-out via message queue
Senior signals
- Message ID ordering with Snowflake-style IDs
- Presence heartbeat design
- Read receipts as separate write path
Design: Rate Limiter
Key decisions
- Token bucket vs. sliding window vs. fixed window
- Where to apply: API gateway vs. service level
- Distributed rate limiting across nodes
Storage choice
Redis with INCR + EXPIRE for counters; Lua scripts for atomic operations
Senior signals
- Sliding window log vs. sliding window counter trade-offs
- Header response design (X-RateLimit-*)
- Graceful degradation when Redis is down
System design interview FAQs
How long should a system design interview be?
Most system design interviews run 45–60 minutes. The split roughly follows: 5 minutes for requirements, 3 minutes for scale estimation, 10 minutes for high-level design, 15 minutes for deep dives on 2–3 components, and 7–10 minutes for scaling discussion and edge cases. The biggest mistake is spending the entire interview on the high-level design and never reaching the component-level depth that separates senior candidates.
What level does system design start appearing in interviews?
System design interviews typically begin at mid-level (L4 at FAANG-equivalent companies) and become a major signal at senior (L5) and above. At junior level, you're evaluated on coding; at senior, architecture and trade-off thinking become the primary signal. At staff and principal level, the scope expands to cross-system design and org-level technical strategy.
Should I use SQL or NoSQL in a system design interview?
Neither is universally correct — the answer depends on your access patterns, consistency requirements, and scale. SQL wins when: you need ACID transactions, your access patterns are well-defined, and your data is relational. NoSQL wins when: you need massive horizontal scale, your schema evolves frequently, or you're doing key-value or document lookups with simple access patterns. The wrong answer is choosing one without justifying it — interviewers want to hear the trade-off reasoning, not just the decision.
How much should I memorize for system design vs. understand?
Memorizing specific numbers (Cassandra throughput, Redis latency) helps with estimation and credibility, but interviewers care far more about whether you can reason about trade-offs than whether you've memorized specific benchmarks. Understand the principles: when to use caching and what to cache, when to denormalize, when fan-out on write beats fan-out on read, how horizontal sharding works. The frameworks transfer to any system; memorized facts only help with the system you memorized.
Practice system design with an AI coach that pushes back.
Zari asks the clarifying questions interviewers use, probes your trade-offs, and tells you exactly where your design breaks down. Start your first session free.
Practice free