System design interviews are less about memorizing answers and more about thinking out loud. When an interviewer asks you, “How would you design Instagram?” they don’t expect you to rebuild the entire company in 30 minutes. What they’re really testing is how you approach complexity, make trade-offs, and communicate your reasoning.
Over the years, I’ve seen the same patterns of questions show up repeatedly. Some focus on scalability, others on reliability, and a few are all about real-time systems. Let’s walk through 20 of the most common system design questions, and instead of rigid templates, I’ll share how I’d think about them in an actual interview.
1. Designing a URL Shortener
This is often the warm-up question. Think Bitly. The core idea is simple: map a long URL to a short, unique code. But the devil is in the details.
You need a way to generate short codes (base62 is common), store the mapping in a database, and then handle redirection when someone visits the short link. Sounds easy, but then the interviewer will ask:
- What if a billion links are created?
- How do you prevent collisions?
- How do you handle analytics and expiration?
That’s your chance to bring in ideas like caching hot links in Redis, retrying collisions, and storing click stats asynchronously.
2. Designing WhatsApp or a Chat System
This one gets tricky fast. A chat system sounds like “just send messages,” but the moment you think about billions of concurrent users, reality kicks in.
Here you want to talk about persistent connections (WebSockets or gRPC), a queue for message delivery, and a database that can store messages even if the user is offline (Cassandra and DynamoDB are common). Throw in read receipts, message ordering, and offline retries, and suddenly you’ve got plenty to discuss.
3. Building a News Feed (Facebook/Twitter)
Feeds are fun to design because they combine storage, ranking, and personalization. At a small scale, you could just fetch all your friends’ posts and show them. At scale? Not so simple.
There are two strategies:
- Fan-out on write (push posts to followers when created).
- Fan-out on read (fetch posts when someone opens the feed).
Both have trade-offs. Push is fast for the reader but heavy for celebrities with millions of followers. Pull is lighter but slower. The best real systems usually combine both.
4. Designing a Notification System
Think emails, SMS, and push alerts. The catch here is reliability and prioritization. An OTP must never arrive late, while a marketing email can wait.
Here you’d want to describe a central event queue, worker services for each channel, retry logic, and monitoring. Bonus points if you mention rate limiting to avoid hammering providers.
5. API Rate Limiting
A very common “mini-design” question. You need a way to stop someone from spamming your API.
Instead of jumping straight into Redis or algorithms, explain the intent: fairness and protection. Then you can walk into algorithms like Token Bucket or Sliding Window, and mention how you’d store counters in Redis for fast checks.
6. Designing Instagram
Now it gets heavier. Storing billions of photos is no joke.
I’d start with where images live: object storage like S3. Metadata (likes, comments, captions) goes into sharded relational or NoSQL databases. A CDN ensures photos load fast globally. And don’t forget the feed system you already talked about earlier.
7. YouTube or a Video Platform
This is an interview favorite. Video adds unique challenges. When you upload, the platform has to transcode into multiple qualities (240p, 720p, 1080p), store it in distributed storage, and then stream chunks via HLS or DASH.
The magic word here is CDN. Without it, buffering would kill the experience.
8. Payment Systems (PayPal/Stripe)
Interviewers love this because it tests your seriousness about consistency and security. Money can’t “eventually” appear.
Talk about ledgers, strong consistency (SQL is better here), encryption, fraud detection, and retries. If you mention PCI compliance, you’ll look prepared.
9. Search Engine Basics
It’s impossible to design Google in an interview, but you can talk about crawling, indexing, and ranking. Explain inverted indexes, caching popular queries, and how ranking algorithms decide order. That shows you know the basics.
10. Designing Uber
Now we’re into real-time geospatial design. You’ll need a location service (to track drivers), a matching service (pair riders with drivers), and a way to handle surge pricing.
If you bring up geospatial databases and in-memory matching, you’ll stand out.
11. Designing Netflix
Another crowd favorite. Here it’s about video storage, adaptive streaming, and personalization. Mention CDNs again, plus recommendation engines powered by collaborative filtering or embeddings.
12. Distributed Cache
Designing a cache tests your fundamentals. Explain partitioning keys, replication, and eviction policies like LRU. Redis is the go-to example.
13. Email System (like Gmail)
Emails are messages with persistence and search. Store them in distributed databases, index them for search, filter spam with ML models, and use queues for reliable delivery.
14. E-commerce Platform (like Amazon)
Product catalog, shopping cart, checkout. Easy to start with, but when you mention consistency in inventory and payments, you show maturity.
15. Dropbox or Google Drive
File storage is all about splitting into chunks, syncing across devices, and managing versions. If you mention delta sync (only uploading changed parts), you’ll impress.
16. Leaderboards for Games
Redis sorted sets are your friend here. Real-time updates with efficient ranking. Mention sharding for global vs regional leaderboards.
17. Logging System
Collect logs with agents (Fluentd, Logstash), push them to Kafka, store in Elasticsearch, visualize in Kibana. Mention retention policies (don’t keep logs forever).
18. Recommendation Systems
Explain collaborative filtering (similar users), content-based filtering (similar items), or hybrid. If you can connect this to vector databases and embeddings, even better.
19. Monitoring System
Metrics → time-series database → alerts → dashboards. Prometheus and Grafana are good examples to drop.
20. Ticket Booking (like BookMyShow)
The real challenge here is avoiding double-booking. Mention locking or optimistic concurrency, strong consistency, and handling huge traffic spikes during popular events.
The best way to prepare for system design interviews is not to memorize diagrams, but to practice explaining trade-offs in plain language. Don’t rush into buzzwords. Start with requirements, design something simple, then add complexity as the interviewer pushes you.
If you practice these 20 questions, you’ll notice a pattern: most systems are built with the same building blocks databases, caches, queues, CDNs, and load balancers. The difference is how you combine them for the problem at hand.
