How to Answer a System Design Interview

How to Answer a System Design Interview

A system design interview is a 45-60 minute conversation where you design a large-scale system. Unlike coding interviews, there is no single correct answer. The interviewer evaluates your thought process, communication, and ability to make tradeoffs.

The 7-Step Framework

Step 1: Clarify Requirements (3-5 minutes)

Never start designing immediately. Ask clarifying questions to narrow the scope.

Questions to ask:

• What are the most important features?
• How many users/requests should the system support?
• What are the latency requirements?
• Is availability or consistency more important?
• Are there any specific constraints (budget, team size, existing infrastructure)?

Why this matters: Designing a chat app for 1,000 users is fundamentally different from designing one for 1 billion users. If you skip this step, you will design for the wrong scale.

Step 2: Define Functional and Non-Functional Requirements (2-3 minutes)

Write down the requirements explicitly. This shows the interviewer you are organized and systematic.

Functional: What the system does (user stories, features) Non-functional: How the system performs (latency, availability, throughput, durability)

Step 3: Back-of-Envelope Estimation (2-3 minutes)

Estimate the scale to drive architectural decisions.

Key estimates:

• Daily active users (DAU)
• Read/write ratio
• Queries per second (QPS) at peak
• Storage requirements (per year)
• Bandwidth needs

Step 4: Design the API (3-5 minutes)

Define the core API endpoints. This clarifies the interface between client and server.

Use RESTful conventions: resource-oriented URLs, proper HTTP methods, clear request/response schemas.

Step 5: Design the Data Model (3-5 minutes)

Identify the core entities and their relationships. Choose between SQL and NoSQL based on access patterns.

Step 6: High-Level Architecture (10-15 minutes)

This is the core of the interview. Draw the architecture on the whiteboard.

Common components:

• Client (web/mobile)
• API Gateway / Load Balancer
• Application Servers
• Database (primary + replicas)
• Cache (Redis/Memcached)
• Message Queue (for async processing)
• CDN (for static content)
• Search Engine (if applicable)

Walk through the data flow: Show how a request travels from client to server and back.

Step 7: Deep Dive and Tradeoffs (10-15 minutes)

The interviewer will ask you to go deeper on specific components. Be prepared to discuss:

• How do you scale the database? (Sharding strategy, shard key choice)
• How do you handle failures? (Replication, failover, circuit breakers)
• What is the caching strategy? (Cache-aside vs write-through, eviction policy)
• How do you ensure consistency? (Strong vs eventual, conflict resolution)
• What are the bottlenecks? (Identify and propose solutions)

Time Management

Communication Tips

1. Think out loud: The interviewer wants to see your thought process, not just the final answer
2. Drive the conversation: Do not wait for the interviewer to guide you. Take ownership of the discussion
3. Acknowledge tradeoffs: For every decision, explain what you are gaining and what you are giving up
4. Be honest about unknowns: It is better to say "I am not sure about this specific detail, but my approach would be..." than to guess incorrectly
5. Use numbers: Back up claims with estimates. "This cache would hold approximately 10GB of data serving 80% of read requests"

Common Mistakes

1. Jumping into details too early without understanding the requirements
2. Not discussing tradeoffs — just stating decisions without justification
3. Over-engineering — designing for 10x the required scale
4. Ignoring non-functional requirements — availability, latency, monitoring
5. Not drawing diagrams — always draw the architecture, even if it is rough
6. Silence — keep talking. Silence makes the interviewer uncertain about your thinking

Source

Framework inspired by System-Design-Overview by Mihadul Dev.