System Design Interview Guide

Master the core architectural patterns behind the world's most popular systems and ace your next system design interview at top tech companies.

Follow this structured approach to tackle any system design interview question effectively.

Select 2-3 core functional requirements that are unique and fundamental to the system being designed (e.g., for a video streaming service: video playback, recommendations, and content delivery rather than login or account management)
Focus on what makes this system unique (e.g., for Twitter, prioritize tweet creation and timeline generation over authentication)
- • Good example (Twitter): Focus on tweet creation, timeline generation, and notification delivery — these highlight the system's unique challenges in content delivery and fan-out
- • Bad example (Twitter): Focus on authentication, user profile editing, and password reset — these are generic features that don't highlight what makes Twitter architecturally interesting
Choosing the right functional requirements directly impacts later design decisions (e.g., focusing on timeline generation leads to discussing fan-out strategies and feed caching, while focusing on authentication leads to more generic discussions)

CAP Theorem: Address whether consistency or availability is prioritized based on specific use cases (e.g., ride-matching services prioritize consistency to avoid double bookings, while fare estimations prioritize availability; e-commerce checkout requires consistency for inventory, but product browsing favors availability)
Available: Specify concrete uptime targets (e.g., 99.99% availability)
Scalable: Define in terms of DAUs or TPS (e.g., 1M DAU, 5000 TPS) and explain why these metrics matter (e.g., "We need to handle 10M daily users with 100:1 read:write ratio, which means our read path must scale to ~1B operations daily")
Fast: Set specific latency targets instead of vague terms (e.g., p50 ≤ 100ms, p99 ≤ 300ms)
Security: Highlight relevant security concerns typically handled by API Gateways/LBs (e.g., rate limiting, WAF for SQL injection protection, DDoS mitigation, authentication/authorization), but call out when specific security needs extra attention (e.g., PII data handling, payment processing, multi-tenant data isolation)

Outline core domain objects that will be referenced in your system (e.g., for a ride-sharing app: User, Driver, Ride, Location, Payment; for a social media platform: User, Post, Comment, Like, Follow)
Design APIs working backward from user experience - what does the user see first and what data is needed?
Map user journey to specific API calls with clear flows (e.g., "When user opens social app → GET /timeline, user taps profile → GET /user/:id, user follows someone → POST /follow/:id; for e-commerce: user searches → GET /products?query=xyz&page=5&limit=50, views item → GET /product/:id, adds to cart → POST /cart/items")
Define data models and how they relate to your API contracts (e.g., for a Twitter-like system: a Tweet object with character limits and metadata in GET /timeline response; for an e-commerce platform: Product object with inventory counts reflected in search results)

Start with a simple design that addresses functional requirements without over-engineering
Progressively enhance the design to address non-functional requirements, explaining why each component is added
Address scalability challenges with specific patterns (e.g., "Our read-to-write ratio is 100:1, so we'll add a Redis cache layer to reduce database load"; "User feed generation is computationally expensive, so we'll use a fan-out-on-write approach with pre-computed feeds"; "Search queries are complex, so we'll implement Elasticsearch for better performance")
Discuss data storage approach and sharding strategies that align with your access patterns
Explain how your design handles failure scenarios while meeting availability targets
Summarize key trade-offs made and potential future improvements

Recommended Resources