System Design Interview Question: How Should You Approach a Design Problem?

System design interviews are open-ended on purpose. Interviewers want to see structured thinking and trade-off reasoning more than a "correct" diagram. This framework works for almost any prompt.

1. Clarify requirements (5 minutes)

• Functional: what must it do? ("Users shorten URLs; anyone can open them; links can expire.")
• Non-functional: scale, latency, availability, consistency, durability.
• Out of scope: say what you won't cover (analytics, admin UI).

2. Estimate the scale (3-5 minutes)

100M new URLs/month  ->  ~40 writes/second (peak maybe 5x: 200/s)
Read:write = 100:1   ->  ~4,000 reads/second
Storage: 100M x 12 months x 5 years x ~500 bytes  ->  ~3 TB

Round numbers are fine. The point is knowing whether you need one database or a hundred.

3. High-level design (10 minutes)

Draw the main boxes: clients, load balancer, stateless API servers, database, cache, queues, object storage, CDN. Walk through one request end to end.

4. Define the API and data model

POST /urls          { longUrl, expiresAt? }  ->  { shortCode }
GET  /{shortCode}   ->  301/302 redirect

urls(short_code PK, long_url, user_id, created_at, expires_at)

5. Deep-dive (15-20 minutes)

Pick the hardest parts, or follow the interviewer's lead: ID generation, caching, sharding, hot keys, failure handling.

6. Discuss trade-offs and bottlenecks

• What fails first as traffic grows 10x? How would you scale it?
• What happens when a component goes down?
• Where did you choose consistency over availability, or the reverse, and why?
• How would you monitor it?

Tips

• Think out loud and check in with the interviewer.
• Start simple, then evolve; don't open with Kafka and 50 microservices.
• Name the trade-off every time you make a choice.