System design interview questions ask you to architect a large-scale system out loud. Interviewers judge your structured thinking, not a single correct answer. The reliable approach is a five-step framework: clarify requirements, define the API, design the data model, scale the system, and discuss trade-offs.
Key Takeaways
- Use a repeatable framework: requirements → API → data model → scaling → trade-offs.
- Always state assumptions and estimate scale (users, QPS, storage) early.
- Know the core building blocks: load balancers, caches, queues, databases, sharding, replication.
- Pair this with our software engineer interview questions and company guides like Google and Amazon.
The 5-Step System Design Framework
- 1. Requirements: Clarify functional needs and non-functional goals (latency, availability, consistency). State assumptions.
- 2. Estimates: Back-of-envelope users, queries per second, read/write ratio, storage.
- 3. API & data model: Define the key endpoints and the schema or storage choice.
- 4. High-level design: Draw the components — clients, load balancer, services, cache, database, queue.
- 5. Scale & trade-offs: Identify bottlenecks; add caching, sharding, replication; discuss CAP trade-offs.
Most Common System Design Questions
| Prompt | Core challenge |
|---|---|
| Design a URL shortener (TinyURL) | Key generation, read-heavy caching |
| Design a rate limiter | Distributed counters, sliding window |
| Design a news feed (Twitter/Instagram) | Fan-out, ranking, caching |
| Design a chat system (WhatsApp) | Real-time delivery, presence, ordering |
| Design a video platform (YouTube) | Storage, CDN, transcoding |
| Design a ride-sharing service (Uber) | Geo-indexing, matching, surge |
| Design a web crawler | Politeness, dedup, distributed frontier |
Worked Example: Design a URL Shortener
- Requirements: Shorten a long URL; redirect; analytics optional. Read-heavy (100:1 read/write).
- API: POST /shorten returns a short code; GET /{code} redirects.
- Data model: Map short code to long URL in a key-value store; codes via base62 of an auto-increment ID or a hash.
- Scaling: Cache hot codes in Redis; the redirect path is a cache hit, not a DB read; CDN at the edge.
- Trade-offs: Hashing risks collisions (need retries); counter-based IDs are predictable. Choose based on requirements.
Worked Example: Design a Rate Limiter
"Use a centralized store like Redis with a sliding-window or token-bucket algorithm. Each server atomically increments a counter keyed by user plus time window using a Lua script to avoid race conditions. For lower latency, a local token bucket handles most traffic and syncs to Redis periodically for global enforcement." Naming a concrete algorithm and the consistency trade-off is what scores points.
Concepts Interviewers Expect You to Know
- CAP theorem: You trade consistency vs availability under partition.
- Caching: Cache-aside, write-through, eviction (LRU), and invalidation.
- Sharding & replication: Horizontal partitioning and read replicas.
- Queues: Decoupling and smoothing spikes with Kafka or SQS.
- Load balancing: Round-robin, least-connections, consistent hashing.
Common Mistakes to Avoid
- Jumping into databases before clarifying requirements.
- Not estimating scale, so your design is over- or under-built.
- Ignoring trade-offs — every choice has a cost; name it.
- Designing silently — interviewers grade your communication.
Practicing System Design With AI
GhOst can produce structured system-design outlines — components, data models, and trade-off analysis — in real time during mock or live interviews, while staying invisible to screen share. See the invisible AI interview assistant guide or the best AI interview assistant roundup.
Frequently Asked Questions
Use a five-step framework: clarify functional and non-functional requirements, estimate scale, define the API and data model, draw the high-level design, then identify bottlenecks and discuss scaling and trade-offs. Communicate out loud throughout.
Design a URL shortener, a rate limiter, a news feed, a chat system, a video platform like YouTube, a ride-sharing service, and a web crawler. Each tests a different core challenge such as caching, fan-out, or geo-indexing.
Know the CAP theorem, caching strategies and eviction, sharding and replication, message queues, load balancing, and consistent hashing. You should be able to name a concrete algorithm and its trade-off for each.
In a 45-minute round, spend about 5 minutes on requirements and estimates, 10 on API and data model, 15 on high-level design, and the rest on scaling and trade-offs. Keep the conversation interactive.
Mostly mid-level and above (L4+). Junior candidates may get a lighter design discussion, while senior and staff roles get deeper, more open-ended system design rounds.
Yes. Tools like GhOst can generate structured design outlines with components, data models, and trade-off analysis in real time, which is useful both for practice and for live, screen-shared interviews.
