System design interviews separate mid-level engineers from senior candidates at Indian product companies. Swiggy, Razorpay, Flipkart, Google India, and Amazon India all conduct system design rounds for senior engineers (5+ years), and the evaluation is not just 'did you design a correct system' but 'do you reason about trade-offs the way a senior engineer at this company would?' This guide covers the 6-step framework, estimation techniques, common questions at Indian companies, and the five most common mistakes that fail candidates.
Step 1 (Requirements, 5 minutes): functional requirements ('what does the system do?') and non-functional requirements ('how does the system perform?'). Ask: 'How many DAU?', 'What is the read:write ratio?', 'What is the acceptable latency?', 'Is strong consistency required or is eventual consistency acceptable?', 'Does the system need to be globally distributed or India-only?'. Step 2 (Capacity estimation, 3-5 minutes): daily active users, requests per second (10M DAU x 10 requests/day = 100M req/day = 1,200 req/sec), storage per year (10M posts/day x 1KB = 10GB/day = 3.6TB/year), bandwidth (1,200 req/sec x 10KB/response = 12MB/sec). Round numbers are fine: the exercise demonstrates whether you can reason about scale, not whether you can compute exactly. Step 3 (High-level architecture, 5 minutes): draw the major components (client, load balancer, API servers, databases, cache, message queue, CDN) and the data flow between them. Do not go deep yet. Step 4 (Data model and API design, 5 minutes): define the 2-3 key database tables or document schemas, the primary access patterns (determines index strategy, partitioning key), and the 3-4 most important API endpoints (method, path, request body, response body). Step 5 (Deep dive, 20 minutes): the interviewer picks 2-3 components to go deep on (database partitioning strategy, caching architecture, message queue design, real-time notification system). This is where the real discussion happens. Step 6 (Bottlenecks and trade-offs, 5 minutes): where will the system fail at scale? What are the trade-offs you made (consistency vs availability per CAP theorem)? What would you change if scale grew 10x?
Common system design questions at Indian companies and the key components for each: Swiggy and Zomato: 'Design a real-time food delivery order tracking system' (geolocation updates from driver apps at 1 Hz via WebSocket or SSE; Redis geo-indexing for driver proximity queries; pub/sub notification to customer app; ETA calculation service using weighted graph with traffic data; state machine for order lifecycle: placed, confirmed, preparing, picked up, delivered). 'Design the Swiggy Instamart 10-minute delivery system' (micro-fulfilment centre (MFC) inventory management; order batching for dark store picker; optimisation: which MFC serves which pincode; real-time inventory depletion handling at high write volume). Razorpay and PhonePe: 'Design a UPI payment processing system' (exactly-once payment semantics with idempotency keys; state machine for payment lifecycle: INITIATED, DEBIT_PENDING, DEBIT_SUCCESS, CREDIT_PENDING, CREDIT_SUCCESS, FAILED; bank API integration with timeout and retry handling; reconciliation batch job). Flipkart: 'Design the Big Billion Days flash sale system' (inventory reservation at 1M requests/minute without overselling: Redis DECR atomic operation for available inventory; virtual waiting room to prevent thundering herd; optimistic locking for order creation vs Redis atomic decrement trade-offs; database sharding by product_id).
Database design concepts tested at senior level: Sharding (horizontal partitioning of a database across multiple nodes; choosing a sharding key: user_id for user data (hot users = hot shards problem), created_at for time-series data (all writes go to the latest shard), consistent hashing to distribute keys across a ring of nodes with minimal rehashing when nodes are added or removed). Replication (primary-replica replication for read scaling: reads go to any replica, writes go to the primary; replication lag and how it affects consistency: a user who just wrote data may not see it immediately on a replica; synchronous vs asynchronous replication: synchronous guarantees durability but adds latency to every write). ACID vs BASE (ACID: Atomicity, Consistency, Isolation, Durability; the property of relational databases; BASE: Basically Available, Soft state, Eventually consistent; the property of distributed NoSQL systems like Cassandra and DynamoDB). CAP theorem (a distributed system can only guarantee two of three: Consistency (every read gets the most recent write), Availability (every request gets a response), Partition Tolerance (system continues operating despite network splits); CP systems: HBase, ZooKeeper; AP systems: Cassandra, DynamoDB; real-world: most systems tune consistency vs availability dynamically based on operation). Index design (B-tree indexes for range queries; hash indexes for exact match; composite indexes: column order matters (the leftmost prefix principle); covering indexes: all columns in the query are in the index, avoiding a table lookup; partial indexes: index only a subset of rows to reduce index size).
Caching architecture depth: Cache-aside pattern (the application reads from cache; on cache miss, reads from database, writes to cache; on cache write, updates database and invalidates or updates cache; Redis is the standard implementation at Indian product companies). Cache invalidation strategies (TTL (Time To Live) based expiry: simple but may serve stale data; event-based invalidation: on database write, publish a cache invalidation event to a pub/sub system; write-through cache: write to cache and database simultaneously; write-behind cache: write to cache first, asynchronously persist to database). Cache sizing (the 80/20 rule: 20% of the data typically accounts for 80% of reads; cache that 20%; for a system with 10M daily active users and 100 bytes of session data each, 1M concurrent sessions x 100 bytes = 100MB Redis cache: trivial to size). Message queue architecture: Kafka vs RabbitMQ vs SQS (Kafka: high-throughput log-based message queue for event streaming at millions of events per second; good for analytics and event sourcing; consumers can re-read old messages by resetting the offset. RabbitMQ: lower-throughput but feature-rich message broker with flexible routing (exchange patterns: direct, topic, fanout, headers); good for task queues and RPC patterns. AWS SQS: managed message queue; Standard (at-least-once delivery, best-effort ordering) vs FIFO (exactly-once delivery, strict ordering at lower throughput; 300 messages/second limit per queue). Idempotent consumer pattern (since Kafka and SQS standard both guarantee at-least-once delivery, every consumer must be idempotent: processing the same message twice must produce the same result as processing it once; use idempotency keys in the database insert).