System Design: Interview Framework
Master the battle-tested 45-minute System Design Interview Framework: clarifying requirements, defining APIs, high-level architectures, deep dives, bottleneck identification, trade-off discussions, and avoiding common interview pitfalls.
1. The 45-Minute System Design Interview Roadmap
A System Design interview is a collaborative open-ended discussion evaluating your ability to navigate ambiguous business problems, formulate technical trade-offs, and scale distributed architectures.
The 45-Minute System Design Interview Time Allocation Roadmap
System DesignStructured milestone breakdown from requirements clarification to deep dives and trade-offs
Phase 1: Scope (0-12m)
Align on requirements and scale.
- Step 1: Clarify Functional & Non-Functional requirements (5m)
- Step 2: Back-of-the-envelope capacity estimations & API definitions (7m)
Phase 2: Build (12-25m)
Design the high-level baseline.
- Step 3: High-Level Design (HLD) architecture diagram & end-to-end data flow (13m)
- Identify primary databases and stateless compute tiers
Phase 3: Scale (25-45m)
Deep dive, harden, and wrap up.
- Step 4: Deep dive into core algorithmic challenges & bottlenecks (13m)
- Step 5: Articulate trade-offs, SRE failure modes & scaling (7m)
2. Step 1: Clarifying Requirements & Scoping
Interview questions are intentionally vague (e.g. "Design Twitter" or "Design a URL Shortener"). You must drive the conversation by establishing explicit boundaries across three categories.
Requirements Scoping Framework (Functional, Non-Functional, Out of Scope)
System DesignStructuring the problem boundary for a URL shortener design
Functional Requirements
Core user-facing capabilities (Pick 3-4).
- Shorten a long URL to a 7-character alias
- Redirect short URL to original destination
- Custom alias creation
Non-Functional Requirements
SRE and operational quality attributes.
- High Availability: 99.99% (Prioritize uptime over immediate consistency)
- Latency: Sub-20ms redirection time
- Scale: 100M new URLs created/month (100:1 read ratio)
Out of Scope
Features explicitly excluded.
- User authentication / accounts
- Real-time analytics dashboard
- Link expiration notifications
3. Step 2 & 3: API Signatures & High-Level Architecture (HLD)
Define clean API contracts before drawing the architecture diagram. Start with a clean, end-to-end baseline connecting clients, edge CDN, API gateway, stateless app servers, in-memory caches, and database storage.
Standard High-Level Architecture (HLD) Topology
System DesignEnd-to-end request flow from Client and CDN Edge to Load Balancer, App Pods, Redis, and Database
API Contract Definition Best Practices
Explicit parameters, return types, and status codes.
- POST /api/v1/urls: { longUrl: string, customAlias?: string } -> 201 Created { shortUrl: string }
- GET /{shortCode}: -> 301 Moved Permanently / 302 Found (Header: Location: longUrl)
- Use 301 for browser caching; use 302 if tracking click analytics on every request
Data Model & Storage Selection
Relational vs NoSQL trade-offs.
- Schema: Table urls(id, short_code [PK], original_url, created_at, user_id)
- NoSQL Key-Value (DynamoDB / Cassandra): Billions of rows, simple key lookup by short_code, easy horizontal partitioning
4. Step 4: Deep Dive into Core Components & Bottlenecks
The deep dive separates senior candidates from juniors. Identify the most critical technical challenge of the system (e.g. generating unique 7-character short codes with zero collisions) and design a specialized component.
Deep-Dive Component Architecture: Key Generation Service (KGS)
System DesignPrecomputing Base62 tokens offline to eliminate runtime hashing collisions and database locks
Key Generation Service (KGS) Architectural Innovation
Eliminating runtime collision retry loops.
- Offline Generation: KGS worker pre-generates random 7-character Base62 keys into a SQL table
- In-Memory Key Ring: Loads 10,000 keys into Redis RAM buffers for instant sub-millisecond retrieval
- Zero Collision Guarantee: When an app server requests a key, KGS marks it assigned; no MD5/SHA256 collision handling required at runtime
Production Base62 URL Short Code Generator & ID Encoder in Node.js
A Base62 encoder that converts numeric IDs into short, URL-safe codes for a link shortener.
Press Run to execute the code and see output here.
5. Step 5: Discussing Trade-offs & Scaling Further
There is no single "perfect" system design,every architectural decision is a compromise between latency, consistency, complexity, and financial cost.
Architectural Trade-Off Decision Radar
System DesignArticulating SQL vs NoSQL, Strong vs Eventual Consistency, and Push vs Pull feed generation
Trade-off Discussions to Highlight
Demonstrating senior engineering maturity.
- CAP Theorem: Why choosing AP (High Availability + Eventual Consistency) is optimal for social feeds and URL shorteners
- Fan-out on Write vs Fan-out on Read: Handling regular users with push models while serving celebrity accounts (e.g. 50M followers) via pull queries
- Database Sharding: Consistent Hashing vs Range Partitioning to avoid single-node hotspots
SRE & Reliability Hardening
Proactively discussing failure modes.
- Cache Stampede Defense: Mutex locking on cache misses
- Circuit Breakers: Fast-failing degraded downstream services
- Multi-Region Replication: Active-Active deployments with Route53 Geo-DNS failover
6. Common System Design Interview Anti-Patterns to Avoid
Avoid these six common pitfalls that frequently lead to poor interview outcomes.
Top 6 System Design Interview Anti-Patterns vs Best Practices
System DesignContrasting silent drawing, early over-engineering, and missing scale with structured communication
Knowledge Check
1. What is the very first step in the 45-minute System Design Interview Framework?
2. Why should candidates explicitly define "Out of Scope" requirements?
3. What is the primary advantage of a Key Generation Service (KGS) in URL Shorteners?
4. What is considered a critical anti-pattern during a system design interview?
5. How should you approach scaling a system during the interview?