System Design Framework & Process

Difficulty: Beginner

Question

What is the step-by-step process for answering a system design interview question? How should you structure your response?

Answer

A structured approach to system design interviews ensures you cover all aspects and demonstrate clear thinking.

The 4-step framework (45 minutes):

1. Requirements & Scope (5 min): Clarify functional and non-functional requirements. Ask questions. Define what is in and out of scope.

2. Capacity Estimation (5 min): Estimate QPS, storage, bandwidth. Identify if the system is read-heavy or write-heavy.

3. High-Level Design (15 min): Draw the architecture. Define core components, APIs, and data flow. Choose database type.

4. Deep Dive (20 min): Dive into 2-3 critical components. Discuss scaling bottlenecks, trade-offs, and specific algorithms.

Key mindset: There is no perfect design. Interviewers want to see your thought process, trade-off analysis, and communication skills.

Code examples

Step 1: Requirements Gathering

// Example: "Design a URL shortener"

// FUNCTIONAL requirements (what the system does)
// Ask: What features are needed?
// - Create short URL from long URL
// - Redirect short URL to original
// - Custom short URLs?
// - URL expiration?
// - Analytics (click tracking)?

// NON-FUNCTIONAL requirements (how the system performs)
// Ask: What are the constraints?
// - How many URLs created per day? (100M)
// - Read:Write ratio? (100:1)
// - Latency requirement? (< 200ms redirect)
// - Availability requirement? (99.99%)
// - URL length? (as short as possible, 7 chars)
// - Retention? (5 years default)

// SCOPE: what's in and what's out
// IN SCOPE:
// - URL shortening and redirection
// - Basic analytics (click count)
// - URL expiration
// OUT OF SCOPE (for this interview):
// - User authentication
// - Billing
// - Detailed analytics dashboard

// Tip: Write these on the whiteboard as you discuss them
// The interviewer wants to see you think before you design

Spending 5 minutes on requirements prevents you from designing the wrong system. Clarify scope, scale, and constraints. Write them down so you can reference them during the design.

Step 2 & 3: Estimation & High-Level Design

// Step 2: Quick estimation
// Write QPS: 100M/day = ~1,200 QPS
// Read QPS: 100M * 100 = 10B/day = ~120,000 QPS
// Storage: 100M * 400B = 40GB/day, 14.6TB/year
// Conclusion: Read-heavy, needs caching

// Step 3: High-Level Design (draw this diagram)

// [Client] --> [Load Balancer]
//                  |
//          [API Servers (stateless)]
//           /        |        \
//    [URL Service] [Analytics] [Cache (Redis)]
//           |         |           |
//      [Database]  [Kafka]    [CDN for redirects]

// Core APIs:
// POST /api/shorten
//   Body: { longUrl, customAlias?, expiry? }
//   Response: { shortUrl, expiresAt }

// GET /:shortCode
//   Response: 302 redirect to longUrl

// GET /api/analytics/:shortCode
//   Response: { clicks, referrers, countries }

// Database choice:
// - URL mappings: PostgreSQL (simple, reliable)
// - Analytics events: Kafka -> ClickHouse (high-volume writes)
// - Cache: Redis (hot URLs)

// Data model:
// urls: { id, short_code(unique), long_url, user_id, created_at, expires_at }

The high-level design connects all components and shows data flow. Define APIs and data models. Choose technologies with brief justifications. This should fit on a whiteboard.

Step 4: Deep Dive & Trade-offs

// Deep dive into 2-3 critical components:

// 1. Short Code Generation (pick one approach and justify)
// Option A: Base62 encoding of auto-increment ID
//   Pro: Simple, no collisions
//   Con: Sequential, predictable
// Option B: Random + check for collision
//   Pro: Unpredictable
//   Con: DB lookup on every create
// Option C: Pre-generated key service
//   Pro: Fast, no collisions, no DB lookup
//   Con: Additional service to maintain
// DECISION: Option C for scale, with fallback to Option A

// 2. Redirect Performance
// Goal: < 50ms redirect latency
// Approach:
//   1. Check Redis cache (0.5ms)
//   2. On miss, query PostgreSQL (2-5ms)
//   3. Store in Redis with 24h TTL
//   4. 302 redirect (not 301, for analytics)
// With Redis: 95% cache hit rate -> avg 1ms

// 3. Scaling Bottleneck Analysis
// Current: 120K read QPS
//   Single Redis: handles 100K+ ops/sec -> 2 Redis nodes
//   PostgreSQL: add read replicas for cache misses
//   API Servers: stateless, scale horizontally
// At 10x: 1.2M read QPS
//   Redis Cluster with sharding
//   Multiple PostgreSQL read replicas
//   CDN caching for popular URLs

// Trade-off discussions:
// - 301 vs 302: 301 is faster (browser caches) but no analytics
// - Custom URLs: allow but check against blocklist
// - Expiration: lazy deletion (check on access) + cron cleanup

// What NOT to do:
// - Don't try to cover everything
// - Don't jump to microservices without justification
// - Don't ignore the interviewer's hints/questions
// - Don't design in silence - think out loud

The deep dive shows depth in 2-3 areas. Present options with trade-offs and make a decision. Discuss scaling bottlenecks and how to address them. Always think out loud so the interviewer can follow your reasoning.

Key points

Concepts covered

Design Process, Requirements Gathering, Trade-offs, Communication, Whiteboarding