System design interviews are the gatekeeping round for senior and above roles at every top Indian tech company. Unlike DSA where there's a right answer, system design is evaluated on your ability to reason through trade-offs, ask the right questions, and arrive at a justifiable architecture — not a perfect one.
Most engineers prepare by memorizing architectures. This doesn't work. Interviewers change requirements mid-round to test adaptability. What works: a repeatable framework applied to any problem, deep knowledge of 10–12 core concepts, and practice designing 8–10 canonical systems out loud.
The 7-Step System Design Framework
Use this framework in every design round. It structures your answer, signals maturity, and prevents you from jumping to solutions before understanding the problem.
Clarify Requirements (3–5 minutes)
Ask about functional requirements (what must the system do?), non-functional requirements (latency, availability, consistency), and explicit constraints (users, QPS, data size). Never assume. Example questions: "Are we building read-heavy or write-heavy?" "What's the acceptable latency for search?" "Do we need global or India-only deployment?"
Estimate Scale (3–4 minutes)
Back-of-the-envelope calculation: DAUs, QPS (read and write separately), storage needed per year, bandwidth. This drives all architecture decisions. Example: "10M DAU × 5 reads/day = 50M reads/day = ~580 reads/second. Write ratio 1:10, so 58 writes/second." These numbers determine whether you need caching, sharding, CDN, etc.
Define APIs (2–3 minutes)
Define 2–4 core API endpoints that represent the system's core functionality. This helps clarify what you're actually building. POST /post (create), GET /feed/{userId}, POST /like/{postId} — simple, clear, shows you understand the product.
High-Level Design (8–10 minutes)
Draw the main components: clients, load balancer, API servers, databases, cache, message queues, CDN. Connect them with arrows showing data flow. This is your high-level architecture — keep it simple first, add complexity only when justified.
Deep Dive on Core Components (10–15 minutes)
The interviewer will guide which component to go deep on — or ask "where's the bottleneck?" Go deep on the hardest part: database schema, sharding strategy, caching approach, message queue design, or the specific algorithm. This is where strong candidates differentiate themselves.
Address Non-Functional Requirements (5 minutes)
Revisit: How do you achieve the required availability (replicas, failover)? How do you handle fault tolerance? How does the system scale horizontally? How do you monitor it? Many engineers skip this — it's often what separates a strong hire from a weak one.
Identify Bottlenecks and Trade-offs (3–4 minutes)
Proactively state what could go wrong and what you'd change. "The current design has a single point of failure at the API server layer — I'd add horizontal scaling with a load balancer. The database is a potential bottleneck at 10K QPS — I'd add read replicas and cache frequently-read data." This shows architectural maturity.
Must-Know Concepts for India System Design Interviews
| Concept | What to Know | When to Apply |
|---|---|---|
| CAP Theorem | Consistency vs Availability vs Partition Tolerance; can only guarantee 2 of 3. CP vs AP systems. | Any distributed system design; especially payments, messaging |
| Database Sharding | Horizontal partitioning strategies: range, hash, directory-based. Resharding challenges. | Any system with 100M+ records or high write throughput |
| Caching (Redis/Memcached) | Cache-aside, write-through, write-back patterns. Cache invalidation strategies. TTL design. | Almost every design; especially read-heavy systems |
| Message Queues (Kafka) | Producer-consumer model, partitions, consumer groups, at-least-once vs exactly-once, lag. | Async processing, event streaming, decoupling services |
| Load Balancing | Round-robin, least connections, consistent hashing. L4 vs L7 load balancers. | Any system with multiple app servers |
| SQL vs NoSQL | When to use relational (ACID, complex queries) vs NoSQL (scale, flexible schema, key-value). | Every design — justify your database choice |
| CDN | Push vs pull CDN, edge caching, cache invalidation, regional distribution. | Media-heavy systems, global reach, static content |
| Rate Limiting | Token bucket, sliding window, fixed window algorithms. Where to implement (API gateway, service level). | Public APIs, payment systems, abuse prevention |
| Consistent Hashing | Distributing requests/data across nodes without full rehashing when nodes change. | Distributed cache design, load balancing, distributed storage |
| Database Replication | Primary-replica setup, synchronous vs asynchronous replication, read replicas, leader election. | High availability systems, read-heavy workloads |
| Distributed Transactions | Two-phase commit (2PC), Saga pattern, eventual consistency, compensating transactions. | Payment systems, order management, financial transactions |
| Search Architecture | Inverted index, Elasticsearch basics, tokenization, relevance scoring. | E-commerce search, social media search, document search |
Top 10 System Design Questions in India 2026
1. Design a URL Shortener (bit.ly)
Key decisions: Hash algorithm (MD5 vs Base62 encoding), handling collisions, cache popular URLs in Redis, redirect speed (301 vs 302), analytics storage, database sharding by hash prefix, expiry mechanism.
2. Design a Food Delivery System (Swiggy/Zomato)
Key decisions: Real-time delivery partner location (WebSocket vs HTTP polling), geospatial queries (PostGIS, H3 indexing), order-partner matching algorithm, push notifications, order state machine design, surge pricing calculation.
3. Design a Payment System
Key decisions: Idempotency keys (double payment prevention), exactly-once processing, ledger database design, saga pattern for multi-service transactions, reconciliation, fraud detection, PCI compliance considerations.
4. Design a Notification System
Key decisions: Multi-channel (push/email/SMS) routing, Kafka for decoupling, priority queues, deduplication, rate limiting per user, template management, delivery tracking, retry with exponential backoff.
5. Design a Social Media Feed (Instagram/Twitter)
Key decisions: Fan-out on write vs fan-out on read (celebrity problem), timeline cache in Redis (sorted sets), content CDN, like/comment counters (approximate vs exact), pagination design, ranking algorithm.
6. Design a Distributed Key-Value Store
Key decisions: Consistent hashing for key distribution, virtual nodes, replication factor (Dynamo-style quorum: W+R>N), conflict resolution (vector clocks, last-write-wins), gossip protocol for node discovery, compaction.
7. Design a Search Autocomplete / Typeahead
Key decisions: Trie data structure for prefix matching vs Elasticsearch, ranking by frequency/recency/personalization, caching top-k suggestions per prefix in Redis, updating trie asynchronously from search logs, internationalization.
8. Design a Ride-Sharing App (Uber/Ola)
Key decisions: Driver location updates (WebSocket, 4-sec interval), geospatial indexing (QuadTree/Google S2), driver matching algorithm (proximity + ratings), surge pricing (demand/supply ratio per hexagon), trip state machine.
9. Design a Video Streaming Service
Key decisions: Video upload pipeline (chunking, transcoding to multiple resolutions), CDN edge caching, adaptive bitrate streaming (HLS/DASH), blob storage (S3-style), recommendation feed, view count approximation at scale.
10. Design a Rate Limiter
Key decisions: Algorithm choice (token bucket vs sliding window log vs sliding window counter), distributed rate limiting with Redis (Lua scripts for atomicity), per-user vs per-IP vs per-endpoint limits, multi-tier rate limiting (API gateway + service level).
Company-Specific System Design Focus Areas
| Company | Favourite Design Topics | What Interviewers Look For |
|---|---|---|
| Google India | Distributed KV store, Search, Pub/Sub systems, MapReduce-style | Deep understanding of distributed systems theory; CAP theorem; correctness |
| Amazon India | E-commerce (catalog, inventory, checkout, notifications), Delivery systems | Scalability at huge load; Amazon LP "Dive Deep"; operational excellence |
| Flipkart | Search, recommendations, Big Billion Day scale, payment flows | India-scale (200M+ users), peak traffic handling, vendor management systems |
| Swiggy / Zomato | Real-time delivery, restaurant search, surge pricing, driver matching | Real-time systems, geospatial, latency sensitivity, food order state management |
| Razorpay / PhonePe | Payment processing, fraud detection, ledger design, reconciliation | Data consistency, idempotency, security design, regulatory compliance |
| CRED | Credit card management, rewards system, bill payment orchestration | Financial system correctness, elegant API design, product thinking |
Common Mistakes in System Design Rounds in India
| Mistake | What It Signals | Fix |
|---|---|---|
| Jumping to solution before clarifying requirements | Poor problem-solving instinct; will build wrong things in real job | Spend first 5 minutes asking questions — this is expected and valued |
| Designing for 100 users when the question implies 100M | Lack of scale thinking; will under-design production systems | Always do back-of-envelope calculation before drawing anything |
| Using a single monolithic database for everything | Junior-level thinking; hasn't worked at scale | Use appropriate storage for each use case: SQL for transactions, NoSQL for profile data, Redis for cache, blob storage for media |
| Not addressing the CAP trade-off for their choices | Doesn't understand fundamental distributed systems constraints | For every database choice, state whether you're choosing CP or AP and why |
| Designing a perfect system with no acknowledged trade-offs | Inexperience — real systems always have trade-offs | Proactively state "This design trades X for Y because…" |
| Going silent or not thinking out loud | Interviewer can't evaluate thinking process; appears stuck | Always narrate your reasoning, even when thinking: "I'm considering two approaches here…" |
System Design Prep Plan — 8 Weeks
| Week | Focus | What to Do |
|---|---|---|
| Week 1–2 | Core concepts | Study: CAP theorem, database types, caching patterns, load balancing, message queues. Read Designing Data-Intensive Applications (Kleppmann) chapters 1–5. |
| Week 3–4 | First 5 canonical designs | Practice: URL shortener, notification system, pastebin, rate limiter, search typeahead. Time yourself (45 min each). Draw diagrams. Say everything out loud. |
| Week 5–6 | Advanced designs | Practice: payment system, social media feed, ride-sharing, video streaming, distributed KV store. Focus on trade-offs and non-functional requirements. |
| Week 7 | Company-specific prep | Research your target company's actual tech stack (engineering blogs). Design systems relevant to their product. Practice the framework with a timer. |
| Week 8 | Mock interviews | Practice with a peer or pay for 2–3 mock interviews on Pramp/Interviewing.io. The act of explaining designs out loud surfaces gaps you didn't know existed. |
Best Resources for System Design Prep in India
| Resource | Type | Best For |
|---|---|---|
| Designing Data-Intensive Applications (Kleppmann) | Book | Deep conceptual understanding — the bible of distributed systems |
| System Design Interview Vol 1 & 2 (Alex Xu) | Book | Structured designs of 20+ systems with good framework |
| ByteByteGo (YouTube + newsletter) | Video + newsletter | Visual explanations of common design problems |
| Engineering blogs (Netflix, Uber, Swiggy, Flipkart) | Technical blogs | Real-world architectures; great for India-specific context |
| Prepflix System Design Track | Course | India-company-specific system design prep with mock rounds |