If you're preparing to switch to a product company — Amazon, Flipkart, Swiggy, PhonePe, Google, or any well-funded startup — and you have 3+ years of experience, you will face a system design interview. This is the round that separates SDE-1 candidates from SDE-2+, and the round that service company engineers find most difficult.
System design interviews don't have a single correct answer. What they test is how you think: how you clarify requirements, how you handle trade-offs, and how well you understand the implications of your choices.
High-Level Design (HLD) vs Low-Level Design (LLD)
| Type | What It Tests | Example Question | Companies That Ask It |
|---|---|---|---|
| HLD | Architecture, scalability, component selection | Design Instagram / Design a payment system | FAANG, Flipkart, Swiggy, Amazon India |
| LLD | OOP, class design, design patterns, clean code | Design a Parking Lot / Design a Chess game | Most mid-product companies, startups, Juspay |
The HLD Interview Framework
- 1Clarify requirements (5 min): Ask about scale, users, features. 'Should it support real-time updates? Is it read-heavy or write-heavy? What's the expected DAU?'
- 2Estimate scale (3 min): Back-of-envelope math. '10M DAU, 100 requests/user/day = 1B requests/day = 12K RPS.'
- 3High-level architecture (10 min): Draw the main components — client, load balancer, app servers, cache, databases, message queue, CDN.
- 4Deep dive (15 min): Pick 2-3 components and go deep — 'How does feed generation work? How do we handle cache invalidation?'
- 5Trade-offs (5 min): SQL vs NoSQL? Availability vs consistency? Push vs pull model? State your reasoning.
- 6Bottlenecks and scaling (5 min): 'What would fail first at 10x scale? How do we shard the database?'
10 Systems to Design Before Your Interviews
- 1URL shortener (bit.ly) — teaches hashing, redirects, rate limiting, analytics
- 2Instagram / image sharing — teaches media storage (S3), CDN, feed generation, sharding
- 3WhatsApp / chat system — teaches WebSockets, message delivery guarantees
- 4Swiggy / food delivery — teaches real-time location tracking, order state machines, multiple actors
- 5Razorpay / payment system — teaches idempotency, distributed transactions, audit logs
- 6YouTube / video streaming — teaches encoding pipelines, chunked uploads, adaptive bitrate, CDN
- 7Google Search — teaches crawling, indexing, inverted index, ranking signals
- 8Rate limiter — teaches token bucket vs leaky bucket, distributed rate limiting with Redis
- 9Notification system — teaches push vs pull, FCM/APNs, fan-out strategies
- 10Ride booking (Uber/Ola) — teaches geospatial indexing, driver matching, real-time tracking
Core Concepts You Must Know
| Concept | Why It Matters | What to Study |
|---|---|---|
| CAP Theorem | Fundamental trade-off in distributed systems | Consistency vs Availability vs Partition tolerance |
| SQL vs NoSQL | Every design needs a database choice + justification | Relational, document, key-value, time-series — use cases for each |
| Caching | Critical for read-heavy systems | Redis vs Memcached, cache-aside vs write-through, TTL, invalidation |
| Message Queues | Async processing, decoupling services | Kafka vs RabbitMQ, pub/sub, consumer groups, at-least-once delivery |
| Load Balancing | Distributing traffic across servers | Round-robin, least connections, consistent hashing |
| Sharding & Replication | Scaling databases beyond one machine | Horizontal sharding, read replicas, eventual consistency |
Resources That Actually Help
- Gaurav Sen on YouTube — best free HLD content in Hindi/English for Indian developers
- ByteByteGo (Alex Xu) — 'System Design Interview' book Vol 1 & 2, excellent structured coverage
- Udit Agarwal / Concept && Coding on YouTube — best free LLD content for Indian developers
- GitHub: ashishps1/awesome-system-design-resources — curated list of free resources
What separates good from great system design answers
'I'd choose Kafka over RabbitMQ here because our write volume requires horizontal scaling of consumers and we need replay capability for audit logs' — not just 'I'd use a message queue.' Every component choice needs a because.