Introduction
A Framework That Works
I've seen candidates with deep technical knowledge bomb system design interviews because they had no structure. They'd jump between caching, database schema, and API design in a stream-of-consciousness monologue, and the interviewer couldn't follow. Meanwhile, candidates with less raw knowledge but a clear framework consistently scored higher because the interviewer could see their reasoning at every step.
Here's the framework. It's not original. It's what most strong candidates converge on naturally, and it maps directly to how the practice problems in this course are structured.
Step 1: Gather Requirements (5 to 10 minutes)
This is where most candidates lose points unnecessarily. The urge to start drawing boxes is strong, but resist it. Spend the first few minutes understanding what you're actually building. The interviewer gave you a vague prompt on purpose. Your job is to turn it into a scoped problem.
Functional requirements define what users can do. For a Twitter-like system, that might be: users can post tweets, follow other users, view a home timeline, search tweets, like and retweet, and receive notifications. Write them down. You'll refer back to this list throughout the interview.
Non-functional requirements define the constraints. These are the questions you should be asking:
- Scale: How many users? How many requests per second?
- Latency: What's acceptable? Sub-200ms for timeline reads?
- Availability vs. Consistency: Can we serve slightly stale data? (Timelines: yes. Payments: no.)
- Read/Write ratio: Is this system read-heavy or write-heavy? This shapes almost every downstream decision.
Write your requirements down visibly. It gives you a reference to check against as you design, and interviewers like seeing structured thinking.
Step 2: Capacity Estimation (2 to 3 minutes)
Quick back-of-envelope math to understand the scale you're designing for. This isn't a math test. Round aggressively and focus on order of magnitude. The point is to inform your design decisions, not to produce an exact number.
QPS: Reads ~500K/sec, Writes ~5K/sec
Storage: 500M tweets/day x 250 bytes = ~125 GB/day = ~45 TB/year
Bandwidth: 500K reads/sec x 1 KB avg response = ~500 MB/sec
Cache: 80/20 rule, 20% of daily reads in cache = ~100 GB Redis
These numbers drive architecture decisions. "At 500K reads/sec, a single database won't cut it. We need caching and read replicas." That's the kind of reasoning the interviewer is looking for. The number itself matters less than the conclusion you draw from it.
Step 3: API Design (3 to 5 minutes)
Define the key endpoints before designing internal architecture. This shows you think from the user's perspective first, which is how good systems get built.
POST /v1/tweets
Body: { content, media_ids[], reply_to? }
Response: { tweet_id, created_at }
GET /v1/timeline/home?cursor=X&limit=20
Response: { tweets[], next_cursor }
POST /v1/users/{id}/follow → 204
GET /v1/search?q=keyword → { results[], next_cursor }A few things worth calling out at this stage:
- Cursor-based pagination for feeds, not offset. Offset breaks when new items are inserted in real time.
- Rate limiting. Mention it briefly: "300 tweets per 3 hours, 1000 follows per day."
- Protocol choice. REST for most operations. WebSocket for real-time updates where the client needs push.
Step 4: High-Level Architecture (10 to 15 minutes)
This is the core of the interview. Draw the system's main components and explain how data flows through them. Start simple. The most common mistake is over-engineering from the start. Begin with the most basic version that works, then add complexity only when your scale numbers demand it.
Here are the building blocks you'll use repeatedly. Not every system needs all of them. A URL shortener doesn't need a CDN or search index. A chat system needs WebSockets but not a CDN. Choose based on your requirements, not a checklist.
| Load Balancer | Distributes traffic across API servers. L7 for HTTP routing, L4 for raw TCP. |
| API Servers | Stateless application logic. Horizontally scalable because there's no local state. |
| Database | SQL for structured, relational data with ACID needs. NoSQL for scale and flexible schemas. |
| Cache | Redis or Memcached for hot data. A well-placed cache can cut database load by 90%. |
| Message Queue | Kafka or SQS for async processing. Decouples producers from consumers, absorbs traffic spikes. |
| CDN | Edge caching for static assets, images, and video. Serves content from the node closest to the user. |
| Object Storage | S3 or GCS for files, images, videos. Cheap, durable, and effectively infinite. |
| Search Index | Elasticsearch for full-text search. Inverted index makes text queries fast. |
"For 1,000 users, a single PostgreSQL instance is fine. At 500K reads/sec, we need read replicas and a caching layer." Start simple, scale when the numbers require it.
Step 5: Deep Dives (15 to 20 minutes)
The interviewer will pick 2 to 3 areas from your architecture to probe. This is where you demonstrate real understanding versus surface familiarity. Expect questions like these:
Database Design
What's the schema? How do you shard? What's the partition key and why? How do you handle hot partitions? What happens during a resharding event?
Caching Strategy
What do you cache and why? Cache-aside vs. write-through? How do you handle invalidation? What's the failure mode if the cache goes down?
Scalability
What's the current bottleneck? How do you scale past it? What breaks at 10x traffic? Where do you scale horizontally vs. vertically?
Failure Handling
What if this service goes down? How do you detect it? What's the recovery path? Do users see errors or does the system degrade gracefully?
Consistency Model
What happens with concurrent writes? Is eventual consistency acceptable here? How do you handle conflicts? What does the user experience look like during a partition?
Data Flow
"Walk me through exactly what happens when a user posts a tweet." Every hop, every service, every database write. This is where hand-wavy answers get exposed.
Principles That Run Through Everything
Always state trade-offs.
Don't just pick a technology. Explain what you gain and what you lose. "Cassandra gives us write throughput and horizontal scaling, but we lose JOIN support and strong consistency. Given our write-heavy workload, that's the right trade-off here."
Think about failure for every component.
For every box in your diagram, have an answer to "what happens when this goes down?" "If Redis fails, reads fall back to the database. Slower, but the system stays functional. We page on-call and restore from the last snapshot."
Don't over-engineer.
Start with the simplest solution that meets your requirements. Add complexity only when your numbers demand it. A microservices architecture for a system with 100 users is a red flag, not a strength.
Drive the conversation.
Don't wait for the interviewer to ask "what about caching?" Proactively identify bottlenecks and address them. "Our read QPS is 500K/sec, so a single database won't handle it. Let me walk through the caching strategy."
Use numbers, not hand-waving.
Quantify whenever possible. "We need to shard because..." is weak. "At 5,000 writes/sec and 500K reads/sec, a single PostgreSQL instance maxes out. We need read replicas and sharding by user_id" is strong. Numbers turn opinions into engineering decisions.
Every problem in the Practice section follows this framework. The first three sub-questions are always functional requirements, non-functional requirements, and API design, followed by capacity estimation and then deep dives tailored to that specific system. Practice the structure enough times and it becomes automatic.