The System Design Interview Framework

The number one reason candidates fail system design interviews isn't a lack of technical knowledge—it's failing to deliver a complete, working system within the time limit. A structured framework prevents this by keeping you on track and ensuring you cover all critical aspects.

Why Structure Matters

Without a framework, it's easy to:

• Spend too long on one area and run out of time
• Get lost in implementation details before establishing the big picture
• Miss requirements that completely change the design
• Never arrive at a complete solution

Following a structured approach gives you confidence, keeps the interviewer engaged, and dramatically increases your chances of success.

The Framework: 5 Phases

System design interviews typically last 45-60 minutes. Here's how to allocate your time:

Where does extra time go? In longer interviews, spend the additional time on High-Level Design and Scaling & Trade-offs—this is where you demonstrate depth and seniority.

Phase 1: Requirements (~5 minutes)

Your goal is to deeply understand what you're being asked to build. Resist the urge to start drawing immediately—a few minutes of clarification will save you from major redesigns later.

Functional Requirements

These define what the system does. Frame them as user capabilities:

"Users should be able to..."

For a URL shortener:

• Users should be able to submit a long URL and receive a shortened version
• Users should be able to visit a short URL and be redirected to the original
• Users should be able to set custom aliases (optional)

Non-Functional Requirements

These define how well the system performs. The key dimensions to clarify:

• Scale: How many users? How many requests per second?
• Latency: What's the acceptable response time?
• Availability: Can we tolerate downtime? (usually no)
• Consistency: Is eventual consistency acceptable, or do we need strong consistency?

Questions to ask:

• "How many daily active users should we design for?"
• "What's our read-to-write ratio?"
• "Is low latency critical for this use case?"
• "How do we prioritize availability vs. consistency?"

Quick Capacity Sanity Check

Once you've clarified the scale, do a 1-2 minute back-of-envelope calculation to inform your design decisions:

"100M users × 1 KB per record = 100 GB—this fits comfortably on a single database, so we won't need sharding."

This quick sanity check prevents over-engineering (adding sharding you don't need) and under-engineering (missing genuine scale challenges). You're not trying to be precise—just determining the order of magnitude and what architectural choices it implies. See Numbers to Know for the key figures and formulas you'll need.

Phase 2: Data Model (~5 minutes)

Before jumping into API design, take a moment to identify the key data objects your system will manage. These entities form the backbone of your data model and help you think clearly about what your APIs will exchange.

Identify Your Entities

Entities are the fundamental "nouns" in your system—the objects that your APIs will create, read, update, and delete, and that your database will persist.

For a URL shortener:

• URL - the mapping between short code and original URL
• User (optional) - if tracking who created URLs

For a ride-sharing app:

• User - riders and drivers
• Ride - a trip from pickup to dropoff
• Location - geographic coordinates
• Payment - transaction records

Keep It Simple

In the interview, this is just a quick bulleted list—not a full schema. You're establishing shared vocabulary with your interviewer.

Data Model:
• URL: shortCode, originalUrl, createdAt, expiresAt
• User: id, email (if auth required)

Phase 3: API Design (~5 minutes)

Before diving into architecture, define the contract between your system and its users. This step is often overlooked but provides crucial structure for your high-level design.

Choose Your Protocol

REST should be your default for most interviews—it's well understood and maps naturally to CRUD operations.

POST /urls
  Request: { "long_url": "https://example.com/very/long/path" }
  Response: { "short_url": "https://short.ly/abc123" }

GET /urls/{short_code}
  Response: 301 Redirect to original URL

GraphQL makes sense when you have diverse clients with varying data needs.

gRPC is appropriate for high-performance service-to-service communication.

Map to Requirements

Each functional requirement should have a corresponding API endpoint. If you can't map a requirement to an API, you may have missed something.

Phase 4: High-Level Design (~15-25 minutes)

This is the core of your interview. Your goal is to create a complete design that satisfies your functional requirements—but resist the temptation to add complexity too early.

Start Simple

Begin with the most straightforward architecture that could work. For most systems, this means:

1. Clients (web, mobile)
2. Load Balancer
3. Application Servers
4. Database

From this foundation, add components only as needed to satisfy requirements.

Talk Through Data Flow

As you draw, narrate how data moves through your system:

"When a user submits a URL, the request hits our load balancer, which routes to one of our application servers. The server generates a unique short code, stores the mapping in our database, and returns the short URL to the client."

This demonstrates your understanding and keeps the interviewer engaged.

What to Include

A complete high-level design typically shows:

• How clients interact with the system
• Request/response flow for each API endpoint
• Where state is stored (databases, caches, queues)
• How components communicate with each other

What to Defer

Save these for scaling discussions:

• Specific database technology choices
• Caching strategies
• Sharding and replication details
• Failure handling and recovery

Phase 5: Scaling & Trade-offs (~15-20 minutes)

With a working design in place, spend your remaining time hardening it. This phase demonstrates senior-level thinking.

What to Address

1. Non-functional requirements: Does your design actually meet the scale, latency, and availability needs?
2. Bottlenecks: What's the weakest link in your system?
3. Edge cases: What happens when things go wrong?
4. Trade-offs: What alternatives did you consider?

Be Proactive (Senior+)

Your level of proactivity here signals your seniority:

• Mid-level: Wait for interviewer prompts, respond thoughtfully
• Senior: Identify issues yourself, propose solutions
• Staff+: Anticipate problems, discuss trade-offs deeply, reference real-world experience

Common Topics

• Database scaling (sharding, read replicas)
• Caching layer design and invalidation
• Rate limiting and abuse prevention
• Monitoring, alerting, and observability
• Disaster recovery and failover

Level Expectations

Interviewers calibrate their expectations based on your target level:

As you grow in seniority, the bar shifts from "can you design this?" to "have you built systems like this?"

Common Pitfalls

Quick Reference Checklist

Before moving to the next phase, verify:

Requirements

• 3-5 functional requirements identified
• Scale, latency, availability clarified
• Assumptions stated and confirmed

Data Model

• Key entities identified
• Basic attributes listed
• Shared vocabulary established with interviewer

API Design

• Each requirement maps to an endpoint
• Request/response formats defined
• Protocol choice justified

High-Level Design

• All functional requirements satisfied
• Data flow explained while drawing
• State storage identified
• Design is complete (not partial)

Scaling & Trade-offs

• Non-functional requirements addressed
• Major bottlenecks identified
• At least one trade-off discussed

Now that you have the framework, let's dive into the key concepts you'll need!