System design rounds decide most senior software roles in India — and they trip up strong coders who have never practised thinking out loud about scale. The good news: interviewers are not testing whether you have memorised an architecture. They are testing whether you can reason through trade-offs. This guide gives you a repeatable framework plus the questions you are most likely to face.
A framework that works for any question
Whatever the prompt, walk through these steps out loud. Interviewers reward structure far more than a "perfect" answer.
- 1Clarify requirements — functional ("users can shorten a URL") and non-functional ("100M reads/day, low latency"). Never start drawing boxes immediately.
- 2Estimate scale — back-of-envelope QPS, storage, and read:write ratio. This drives every later decision.
- 3Define the API — the handful of endpoints the system exposes.
- 4High-level design — client, load balancer, app servers, database, cache, queue. Draw the happy path.
- 5Deep-dive a component — pick the hardest part (the data model, the cache strategy, the bottleneck) and go deep.
- 6Discuss trade-offs — consistency vs availability, SQL vs NoSQL, sharding, replication, failure handling.
The most-asked system design questions
Classic design problems
- Design a URL shortener (TinyURL) — tests hashing, key generation, read-heavy caching.
- Design a rate limiter — token bucket vs sliding window, where it lives.
- Design a news feed (Instagram/Twitter) — fan-out on write vs read, ranking.
- Design a chat system (WhatsApp) — websockets, delivery receipts, message storage.
- Design a ride-hailing service (Uber/Ola) — geospatial indexing, matching, surge.
- Design a video streaming service (YouTube/Hotstar) — CDN, encoding, storage tiers.
Infrastructure & scale questions
- How would you scale a read-heavy service to 10M users?
- How do you keep a cache consistent with the database?
- How do you design for high availability across regions?
- When would you choose NoSQL over a relational database?
- How do you handle a thundering-herd / hot-key problem?
India-specific signals to weave in
For roles at Indian product companies (Flipkart, Swiggy, Razorpay, Zomato), interviewers love when you reason about peak-load events (sale days, IPL, festivals), UPI/payment idempotency, and mobile-first, low-bandwidth constraints. Mentioning these shows real-world maturity.
How to actually get good at this
System design is a spoken skill. You cannot learn it only by reading — you have to practise articulating a design under time pressure. Study the patterns, then rehearse explaining them aloud until the framework is automatic.
Practise system design and 19+ topics with guided questions
Start Interview PrepWhen you are ready to simulate the real thing, run a voice-based AI mock interview that asks follow-ups and grades your answers — the closest thing to a live panel without the nerves.
Frequently asked questions
How do I start a system design interview?
Always start by clarifying functional and non-functional requirements, then estimate scale (QPS, storage, read:write ratio). Jumping straight to drawing the architecture is the most common mistake.
What do interviewers actually look for?
Structured reasoning and trade-off awareness — not a single "correct" architecture. They want to see you handle ambiguity, justify decisions, and identify bottlenecks.
How long should I prepare for system design?
For most engineers, 2–4 weeks of practising 1–2 designs per day aloud is enough to internalise the framework. Mock interviews accelerate this significantly.