System design interviews test whether you can think through large-scale software architecture on the spot. Unlike coding rounds, there is no single correct answer. Interviewers want to see how you break down ambiguous problems, make tradeoffs, and communicate your reasoning.
This guide covers the core concepts, a repeatable framework, and the most commonly tested topics at companies like Google, Meta, Amazon, and Stripe.
Why system design matters
At the intern and new grad level, system design rounds are becoming more common, especially at mid-to-large tech companies. Even when the round is labeled "technical discussion" or "architecture," it is often a system design interview in disguise.
The bar is lower than for senior candidates. Nobody expects you to know the internals of Cassandra or debate Paxos vs. Raft. What they do expect is clear thinking: can you sketch a reasonable system, identify bottlenecks, and talk through your decisions?
A repeatable framework
Every system design question can be approached with the same four-step structure. This keeps you organized and makes it easy for the interviewer to follow along.
1. Clarify requirements (3-5 minutes)
Never start designing immediately. Ask questions first. You want to nail down:
- Functional requirements - What does the system actually need to do? What are the core user actions?
- Non-functional requirements - How many users? What latency is acceptable? Does it need to be globally distributed?
- Scope - What is out of scope? The interviewer will appreciate you explicitly cutting things.
For example, if the question is "Design Twitter," you might ask: Are we focusing on the tweet timeline, or also DMs and search? What is the expected read-to-write ratio? Is the user base global?
2. High-level design (10-15 minutes)
Draw the major components on the whiteboard (or describe them verbally). Start with the obvious pieces:
- Client (web/mobile)
- API layer or load balancer
- Application servers
- Database(s)
- Cache layer
- Any async processing (queues, workers)
At this point you are sketching the 10,000-foot view. Don't get into specific database schemas or API contracts yet. The goal is to show the interviewer that you understand how data flows through a system from the user's request to the response.
3. Deep dive (10-15 minutes)
Now the interviewer will ask you to zoom into specific areas. This is where you show depth. Common deep-dive topics:
- Database choice - SQL vs. NoSQL, and why. What does the schema look like? How do you handle indexing?
- Scaling - Horizontal vs. vertical scaling. Sharding strategies. Read replicas.
- Caching - Where do you cache? What eviction policy? How do you handle cache invalidation?
- Data consistency - Strong vs. eventual consistency. What happens during a network partition?
4. Wrap up (2-3 minutes)
Summarize what you designed and mention what you would improve with more time. This shows self-awareness and maturity. Good things to mention: monitoring/alerting, rate limiting, security considerations, or graceful degradation.
Core concepts you should know
Load balancing
A load balancer distributes incoming traffic across multiple servers. It prevents any single server from becoming a bottleneck. The most common approaches are round-robin (requests go to servers in rotation) and least-connections (requests go to the server handling the fewest active connections).
Caching
Caching stores frequently accessed data in fast storage (usually in-memory, like Redis or Memcached) so you don't need to hit the database every time. Key concepts:
- Cache-aside - The application checks the cache first, and on a miss, reads from the DB and populates the cache.
- Write-through - Every write goes to both the cache and the DB at the same time.
- TTL (Time to Live) - Cached entries expire after a set duration to prevent stale data.
Database scaling
When a single database can't keep up, you have a few options:
- Read replicas - Copies of the primary DB that handle read queries. Great when reads far outnumber writes.
- Sharding - Splitting data across multiple databases by some key (user ID, geography, etc.). Powerful but adds complexity.
- Denormalization - Storing redundant data to avoid expensive joins. Common in NoSQL systems.
Message queues
Queues (like Kafka, RabbitMQ, or SQS) let you decouple components. Instead of one service directly calling another, it drops a message on a queue and a worker picks it up later. This is useful when processing doesn't need to happen in real time: sending emails, generating thumbnails, updating search indexes.
CAP theorem
A distributed system can provide at most two of these three guarantees: Consistency (every read returns the latest write), Availability (every request gets a response), and Partition tolerance (the system keeps working even if network connections between nodes drop).
In practice, network partitions will happen, so you are really choosing between consistency and availability. Most real-world systems lean one way or the other depending on the use case.
Common system design questions
These come up over and over in interviews at all levels. Practice at least a few of them out loud before your interview.
- Design a URL shortener (like bit.ly)
- Design a news feed / timeline (like Twitter or Instagram)
- Design a chat application (like Slack or WhatsApp)
- Design a rate limiter
- Design a notification system
- Design a file storage service (like Google Drive or Dropbox)
- Design a web crawler
- Design a key-value store
For each one, practice going through the four-step framework. Time yourself. The biggest mistake candidates make is spending too long on requirements and running out of time before the deep dive.
Tips for the actual interview
- Think out loud. The interviewer cannot give you credit for reasoning that stays in your head. Narrate your thought process, even when you are uncertain.
- Make tradeoffs explicit. Don't just say "I'd use a NoSQL database." Say "I'd use a NoSQL database here because the data is mostly denormalized and we need high write throughput, but the tradeoff is weaker consistency guarantees."
- Use numbers. Back-of-the-envelope math goes a long way. If you know each user generates 10 requests per day and there are 100M users, you can estimate QPS and storage needs. Interviewers love this.
- Don't memorize solutions. Interviewers can tell. Instead, understand the building blocks (caching, queues, partitioning, replication) and assemble them for each question.
- It's okay to not know something. Saying "I'm not sure how X works internally, but my understanding is..." is much better than making things up.
Where to go from here
This guide gives you the foundation. To go deeper, look at real interview questions from companies you're targeting. Seeing what specific companies ask (and how detailed they expect answers to be) is worth more than reading another generic guide.