System design interviews test whether you can think about software at scale. The good news: every system design question follows the same framework. Master the framework, and you can design anything.
The 4-Step Framework (Use This Every Time)
Step 1: Clarify Requirements (3-5 minutes)
Don't start designing. Ask questions first:
- What are the core features? (MVP, not everything)
- How many users? (thousands vs. millions changes everything)
- Read-heavy or write-heavy?
- Latency requirements? (real-time vs. eventual consistency)
- Any specific constraints? (geographic distribution, compliance)
Step 2: High-Level Design (10 minutes)
Draw the big boxes: clients, load balancer, API servers, database, cache, message queue. Don't optimise yet — get the data flow right first.
Step 3: Deep Dive (15-20 minutes)
The interviewer will say "tell me more about X." This is where you show depth: database schema, API design, caching strategy, how you handle failures.
Step 4: Scaling and Trade-offs (5 minutes)
Discuss: where are the bottlenecks? How would you handle 10x growth? What would you sacrifice — consistency, latency, cost?
The 7 Patterns That Cover 90% of Questions
- Load balancing + horizontal scaling — more servers behind a balancer
- Database sharding — split data across multiple DB instances
- Caching layer — Redis/Memcached for hot data
- Message queues — decouple producers and consumers (Kafka, SQS)
- CDN for static content — serve assets from edge locations
- Database replication — read replicas for read-heavy workloads
- Event-driven architecture — react to changes instead of polling
Example: Design a URL Shortener
Requirements: 100M URLs/month, redirect latency <50ms, URLs expire after 5 years.
Design: API server generates a 7-char base62 hash. Store in a sharded PostgreSQL (hash prefix determines shard). Redis cache for hot URLs (80/20 rule — 20% of URLs get 80% of traffic). CDN for the redirect HTML. Counter service for analytics.
Scale discussion: At 100M URLs, each 7-char hash gives 3.5 trillion combinations — no collision risk. Reads dominate writes 100:1, so cache-first architecture. Database is the bottleneck for writes; shard by hash prefix.
Practice Strategy
Design two systems per week for 4 weeks. Cover: URL shortener, chat system, notification service, news feed, rate limiter, web crawler, payment system, search autocomplete.
For real-time system design guidance, CodeSage Pro has a dedicated System Design mode.