Skip to content
System Design
System design interviews can be intimidating, especially when you are asked to architect a system that can handle millions of users. The key to success isn’t memorizing specific technologies or architectures — it’s following a structured approach that demonstrates your ability to think systematically about complex problems.
After conducting hundreds of system design interviews and helping engineers land roles at top tech companies, I’ve distilled the process into a repeatable framework that works every time.
Why System design interviews matter?
System design interviews evaluate your ability to:
- Think at scale and understand trade-offs
- Break down complex problems into manageable components
- Communicate technical concepts clearly
- Design systems that are reliable, scalable, and maintainable
Unlike coding interviews, there’s no single “correct” answer. Interviewers want to see your thought process and how you handle ambiguity.
The 7-Step framework for System design success
Step 1: Clarify requirements and scope (5–10 minutes)
Never jump straight into designing. Start by asking clarifying questions to understand exactly what you are building.
- What specific features need to be supported?
- Who are the primary users?
- What are the core user journeys?
- How many users do we expect?
- What’s the read/write ratio?
- What are our availability requirements?
- Are there any specific performance requirements?
- Do we need real-time features?
- “Should we support media uploads or just text?”
- “Do we need to handle celebrity users with millions of followers differently?”
- “What’s our target latency for the timeline feed?”
Step 2: Estimate scale and identify constraints (5 minutes)
Use back-of-the-envelope calculations to understand the scale you are designing for. This helps identify potential bottlenecks early.
- Daily Active Users (DAU)
- Read and write requests per second
- Storage requirements
- Bandwidth requirements
- 100M DAU
- Each user posts 2 tweets/day → 200M writes/day → ~2,500 writes/second
- Each user reads 100 tweets/day → 10B reads/day → ~115,000 reads/second
- Read:Write ratio = 46:1 → read-heavy system, optimize for reads
Step 3: Design high-level architecture (10 minutes)
Start with a simple, high-level design that addresses the core functionality. Think of this as your system’s skeleton.
- Client applications (web, mobile)
- Load balancers
- Application servers
- Database layer
- Content Delivery Network (CDN) for static assets
Draw boxes and arrows showing the flow of data. Keep it simple initially — you will add complexity later.
Step 4: Design core components (15–20 minutes)
- POST /api/v1/tweets
- GET /api/v1/timeline/user/{userId}
- GET /api/v1/timeline/home/{userId}
- Users: user_id, username, email, created_at
- Tweets: tweet_id, user_id, content, created_at
- Follows: follower_id, followee_id, created_at
- User Service: Handle authentication and user management
- Tweet Service: Create and store tweets
- Timeline Service: Generate user feeds
- Notification Service: Handle real-time updates
Step 5: Scale your design (10–15 minutes)
- Read replicas for read-heavy workloads
- Sharding for write scalability
- Partitioning strategies (user_id, region)
- Application-level caching (Redis/Memcached)
- CDN for static content
- Database query result caching
- Pre-computed timeline caches for active users
- Break monolith into smaller services
- API gateways for routing/authentication
- Message queues for asynchronous processing
Step 6: Address reliability and consistency (5–10 minutes)
- Circuit breakers to prevent cascade failures
- Retry mechanisms with exponential backoff
- Health checks and monitoring
- Multi-region deployment for disaster recovery
- Eventual consistency for timeline feeds
- Strong consistency for financial transactions
- Distributed consensus algorithms where needed
Step 7: Monitor and optimize (5 minutes)
- Application Performance Monitoring (APM)
- Database performance metrics
- Infrastructure monitoring (CPU, memory, disk)
- Business metrics (user engagement, system usage)
- Database query optimization
- Caching hit rate improvements
- Load balancing adjustments
- Auto-scaling policies
Common mistakes to avoid
- Don’t start with complex architectures — begin simple
- Don’t ignore the requirements
- Don’t over-engineer — design for the scale you actually need
- Don’t forget about data consistency
- Don’t skip monitoring discussion — production systems need observability
Technology choices and trade-offs
- SQL vs NoSQL: SQL = strong consistency, complex queries; NoSQL = horizontal scaling, flexible schema
- Synchronous vs Asynchronous: Sync = simpler, immediate feedback; Async = scalable, fault-tolerant
- Consistency Models: Strong, Eventual, Weak consistency
Sample timeline for a 45-Minute Interview
- 0–8 min: Requirements gathering & scope definition
- 8–13 min: Scale estimation & constraint identification
- 13–23 min: High-level architecture design
- 23–38 min: Core components & scaling deep dive
- 38–43 min: Reliability, monitoring, trade-offs discussion
- 43–45 min: Questions & wrap-up
Practice makes perfect
Work through classic problems:
- Beginner: URL Shortener, Chat Application, File Storage System
- Intermediate: Social Media Feed, Ride-sharing, Video Streaming Platform
- Advanced: Search Engine, Distributed Cache, Real-time Analytics Platform
Follow the 7-step framework, time yourself, and practice explaining your thought process out loud.
Key takeaways
- Start simple and add complexity incrementally
- Justify design decisions with trade-offs
- Consider both functional and operational requirements
- Plan for failure scenarios and handle them
- Practice regularly with realistic time constraints
The goal isn’t to design the perfect system — it is to show that you can think systematically about complex problems and make informed architectural decisions. With consistent practice using this framework, you will be well-prepared to tackle any system design interview.
Ready to practice? Pick one of the sample problems mentioned above and walk through the 7-step framework. Time yourself for 45 minutes and focus on explaining your reasoning at each step. The more you practice, the more natural this process becomes.
