System Design Interview Prep for Indian Engineers

Why good engineers freeze at the whiteboard

A classic way to fail a system design round goes like this. The interviewer asks you to design a URL shortener like bit.ly. Simple enough: you've used URL shorteners a thousand times and know the concept cold. But with the marker in your hand, your brain goes blank. You start rambling about databases without asking about requirements, never mention scale, skip caching and forget to discuss trade-offs. Thirty minutes later the interviewer thanks you politely, and you know it's over.

It's a lesson a lot of engineers learn the hard way. There's no single "right" answer in system design. Companies want to watch you think in a structured way. Can you break down a fuzzy problem? Can you weigh trade-offs out loud, and can you respond when someone pushes back on your design? That's what they're scoring.

The fix is structured preparation. This guide lays out a repeatable framework, two full walkthroughs and the concepts interviewers expect, so you're never improvising from a blank board.

How companies frame these questions

Formats differ from company to company. The core expectations stay pretty consistent.

FAANG (Google, Amazon, Meta, Apple, Netflix)

• Duration: 45 minutes (sometimes 60)
• Format: an open-ended problem, with the interviewer acting as a collaborative partner
• Evaluation: requirements gathering, high-level design, a deep dive into components, trade-off analysis, scalability discussion
• Expected level: senior (L5+) candidates almost always face this round, and some companies include it for mid-level (L4) too

Indian companies (Flipkart, Razorpay, Zerodha, Swiggy, PhonePe)

• Duration: 45-60 minutes
• Format: similar to FAANG, often with more weight on practical, India-specific constraints (high traffic during sales, payment system reliability, vernacular support)
• What's different: Flipkart might ask you to design for Big Billion Days traffic. Razorpay wants you thinking about payment idempotency, and Zerodha cares about real-time data at scale with minimal latency.

Commonly asked questions

A four-phase framework for your 45 minutes

This framework keeps you on track and covers what the interviewer expects. The timings are approximate, but they stop you from burning 20 minutes on one section and having nothing left for the rest.

Phase 1: Requirements and scope (5-7 minutes)

Don't skip this. So many candidates jump straight into boxes and arrows, and it's a reliable way to go sideways. Spend the first few minutes asking clarifying questions until you know what you're building.

Functional requirements, or what the system should do:

• What are the core features?
• Who are the users?
• What are the key user flows?

Non-functional requirements, or how the system should behave:

• What's the expected scale? (DAU, requests per second, data volume)
• What are the latency requirements?
• What's the availability target? (99.9%? 99.99%?)
• Is consistency or availability more important? (CAP theorem territory)

Back-of-the-envelope estimation:

• Quick math on storage, bandwidth, and QPS
• It shows the interviewer you think about scale in concrete numbers

Phase 2: High-level design (10-12 minutes)

Sketch the major components and how they interact:

• API design (key endpoints)
• Core services/microservices
• Database choices (SQL vs NoSQL, and why)
• Data flow between components

Don't go deep into any single component yet. You're painting the big picture so the interviewer can see where you're headed and steer if they want to.

Phase 3: Deep dive (15-20 minutes)

Now the interviewer will probably pick one or two components to explore in detail, and this is where your knowledge of specific technologies and patterns counts:

• Database schema design
• Caching strategy
• Data partitioning and sharding
• Consistency models
• API rate limiting
• Failure handling

Phase 4: Scaling and trade-offs (5-8 minutes)

Talk through how the system handles growth:

• Horizontal scaling strategies
• Single points of failure and how to remove them
• Monitoring and alerting
• The trade-offs you made, and why

Design walkthrough 1: URL shortener

This is the question from the opening, so here's how to answer it well. It's probably the most frequently asked system design question out there, and with reason: it's small enough to scope in 45 minutes and deep enough to test real knowledge.

Phase 1: Requirements

Functional:

• Users can submit a long URL and receive a shortened URL
• Clicking the short URL redirects to the original URL
• Optional: custom aliases, expiration dates, click analytics

Non-functional:

• High availability (links should always work)
• Low latency for redirection (< 100ms)
• Short URLs should be as short as possible
• Not easily guessable (no sequential IDs)

Scale estimation:

• 100 million new URLs per month (write-heavy creation)
• 10 billion redirects per month (read-heavy usage)
• Read:Write ratio = 100:1
• Average URL length: 200 bytes
• Storage per year: 100M * 12 * 200B = ~240 GB (manageable)
• QPS for reads: 10B / (30 * 24 * 3600) = ~3,850 reads/second
• Peak QPS: ~10,000 reads/second

Phase 2: High-level design

Client -> Load Balancer -> API Servers -> Cache (Redis)
                                      -> Database (read replicas)
                                      -> ID Generator Service

API design:

POST /api/shorten
  Body: { "url": "https://example.com/very/long/path", "custom_alias": "mylink" }
  Response: { "short_url": "https://short.ly/abc123" }

GET /:shortCode
  Response: 301 Redirect to original URL

The big decision is how to generate the short code.

Option A is to hash the URL (MD5/SHA256) and take the first 7 characters. The problem is collisions.

Option B is to pre-generate unique IDs with a distributed ID generator (like Snowflake or a counter-based service) and encode them in Base62. It's the cleaner approach.

I'd go with Base62 encoding of a unique ID. A 7-character Base62 string gives 62^7 = 3.5 trillion possible URLs, far more than this scale needs.

Phase 3: Deep dive into database and caching

For the database, a simple key-value store works perfectly, because the access pattern is "given a short code, return the long URL." Options include:

• DynamoDB or Cassandra for high write throughput and horizontal scalability
• PostgreSQL with good indexing if you need relational features (analytics, user accounts)

I'd choose DynamoDB for the core URL mapping (short_code -> long_url). The access pattern is a pure key-value lookup, and DynamoDB handles that at massive scale with single-digit millisecond latency. It looks like the cleanest fit to me.

Schema:

Table: url_mappings
  short_code (PK): String  -- "abc123"
  long_url: String          -- "https://example.com/..."
  created_at: Timestamp
  expires_at: Timestamp (optional)
  user_id: String (optional)
  click_count: Number

Reads outnumber writes 100:1, so caching is clearly worth it. Put a Redis cache in front of the database (our Redis caching practical guide covers the implementation details in depth):

1. On a redirect request, check Redis first
2. On a cache hit, redirect immediately (< 5ms)
3. On a cache miss, query DynamoDB, cache the result, then redirect
4. Use an LRU eviction policy
5. Cache size: the top 20% of URLs likely handle 80% of traffic (Pareto principle). With 1.2 billion URLs, cache 240 million. At ~200 bytes each that's ~48 GB of Redis, which a Redis cluster can handle.

Phase 4: Scaling

• API servers are stateless, so horizontal scaling behind a load balancer is straightforward
• DynamoDB scales automatically with provisioned or on-demand capacity
• The Redis cluster can be sharded by short_code hash
• 301 vs 302 redirect: use 301 (permanent) so browsers can cache it and server load drops. Use 302 if you need accurate click analytics, since a 301 may bypass your server on later clicks.

Design walkthrough 2: chat system (WhatsApp-like)

Phase 1: Requirements

Functional:

• One-on-one messaging
• Group messaging (up to 1,024 members)
• Online/offline status
• Message delivery receipts (sent, delivered, read)
• Media sharing (images, videos)

Non-functional:

• Real-time message delivery (< 500ms)
• Messages must never be lost
• High availability
• End-to-end encryption

Scale: 500 million DAU, each sending 40 messages/day = 20 billion messages/day = ~230,000 messages/second. Huge numbers.

Phase 2: High-level design

Client <-> WebSocket Gateway <-> Chat Service <-> Message Queue (Kafka)
                                                -> Message Storage (Cassandra)
                                                -> User Service
                                                -> Media Service (S3)
                                                -> Push Notification Service

Why WebSockets? Chat needs bidirectional, real-time communication, and HTTP polling wastes resources. A WebSocket keeps a persistent connection open so the server can push messages instantly. No contest.

Phase 3: Deep dive into message delivery

When both users are online:

1. User A sends a message through their WebSocket connection
2. Chat Service identifies User B's WebSocket gateway server
3. The message is forwarded straight to User B through their WebSocket connection
4. A delivery receipt goes back to User A

When the recipient is offline:

1. The message is stored in Cassandra with delivery status = "sent"
2. A push notification goes out via FCM (Android) or APNs (iOS)
3. When User B comes online, their client pulls all undelivered messages
4. Delivery status updates to "delivered"

How do you find which server a user is connected to?

• Run a presence service on Redis: user_id -> gateway_server_id
• When a user connects via WebSocket, register their server in Redis
• When they disconnect, remove the entry
• Use a heartbeat to detect stale connections

Message storage in Cassandra:

Table: messages
  Partition Key: chat_id (conversation ID)
  Clustering Key: message_id (TimeUUID for chronological ordering)
  Columns: sender_id, content, timestamp, status, media_url

Why Cassandra? I think it fits well here because:

• The workload is write-heavy (230K writes/second)
• The access pattern is time-series (load messages in chronological order)
• It scales horizontally through partitioning without much fuss
• Consistency is tunable (you can prioritize availability)

Phase 4: Scaling considerations

• WebSocket gateways need to hold millions of concurrent connections. Each server handles ~100K connections, so for 500M DAU with ~100M concurrent at peak you'd need ~1,000 gateway servers.
• Kafka sits as a buffer between the chat service and storage, which prevents message loss during traffic spikes.
• End-to-end encryption means the server never sees plaintext; only the clients have the keys. It's not a trivial implementation and typically uses the Signal Protocol.

Key concepts you can't skip

Load balancing

A load balancer spreads traffic across multiple servers. Know these algorithms:

• Round Robin: simple rotation, works for stateless services
• Least Connections: routes to the server with the fewest active connections
• Consistent Hashing: routes based on a hash of the request, useful for cache-friendly routing

Caching

The layers, from closest to the user outward:

1. Browser cache (client-side)
2. CDN (edge servers geographically close to users)
3. Application cache (Redis/Memcached)
4. Database query cache

For invalidation you have write-through (update the cache on write), write-behind (async cache update), cache-aside (the application manages the cache) and TTL-based expiration. Pick the wrong one and you'll spend weeks debugging stale data. I suspect cache invalidation causes more production incidents than people admit.

Database sharding

Sharding splits a large database across multiple servers. Common strategies:

• Range-based: shard by ID range (1-1M on shard 1, 1M-2M on shard 2)
• Hash-based: hash the shard key and mod by the number of shards
• Geography-based: Indian users on an India shard, US users on a US shard

Each one costs you something. Range-based sharding can create hotspots, hash-based sharding makes range queries harder, and geography-based sharding works well for user-specific data but not for global data.

CAP theorem

In a distributed system you can only guarantee two of these three:

• Consistency: every read gets the most recent write
• Availability: every request gets a response
• Partition tolerance: the system works despite network failures

Network partitions are unavoidable, so the real choice is between CP (consistent, but may reject requests) and AP (always responds, but may serve stale data). Banking systems choose CP. Social media feeds choose AP. Knowing when to pick which is probably the most important thing you can signal in an interview.

Message queues

Queues let services talk asynchronously. Kafka is for high-throughput event streaming, RabbitMQ for task queues, and SQS for simple cloud-native queuing.

Reach for a message queue when you need to:

• Decouple services
• Absorb traffic spikes (buffering)
• Guarantee message delivery (at-least-once)
• Build an event-driven architecture

Don't throw a queue into every design because it sounds impressive. Use one when there's a clear reason for async processing.

Mistakes I've made (and keep seeing others make)

1. Not clarifying requirements

This is jumping into a solution before you understand the problem. Spend those first 5 minutes asking questions, because interviewers specifically check whether you clarify ambiguity. Skip it and you're telling them you build first and think later.

2. Over-engineering

Designing for billions of users when the question implies thousands is a common trap. Start simple and scale up when the interviewer pushes. A monolith is perfectly fine for the initial design, and you can bring up microservices as a scaling step. I've seen candidates draw 15 microservices for a system that could have been a single Node.js server with a PostgreSQL database.

3. Ignoring trade-offs

Every design decision costs something: SQL vs NoSQL, consistency vs availability, latency vs throughput. Interviewers want to hear you spell those costs out instead of picking whatever is popular on tech Twitter. "I chose Cassandra because everyone uses it" is a terrible answer. "I chose Cassandra because our write-heavy workload benefits from its LSM-tree storage engine, though we're trading away strong consistency" is the answer that gets you hired.

4. Skipping the back-of-the-envelope math

"We'll use a database" is weak. "We need to store 240 GB per year, so a single PostgreSQL instance handles this easily" shows you understand the actual scale. The math isn't hard. It's what separates people who think in abstractions from people who think in real systems.

5. Forgetting about failure

What happens when a server crashes, or the database goes down, or a network partition hits? Talking through failure modes and recovery shows maturity. I think most junior candidates forget this entirely, which makes it one of the easiest ways to stand out.

Resources that helped me prepare

Books

• "Designing Data-Intensive Applications" by Martin Kleppmann: I'd argue it's the best single book on distributed systems concepts. Dense but thorough, and worth a second read.
• "System Design Interview" by Alex Xu (Vol 1 & 2): practical, structured walkthroughs of common design problems. Great for pattern recognition and building muscle memory.

YouTube channels

• Gaurav Sen: clear explanations of system design concepts with good diagrams. His videos on consistent hashing and load balancing are outstanding.
• Tech Dummies Narendra L: detailed, practical system design walkthroughs, very popular among Indian engineers for good reason.
• ByteByteGo (Alex Xu): clean animations that explain complex distributed systems concepts in digestible chunks.

Practice platforms

• interviewing.io: anonymous mock interviews with real engineers from FAANG companies
• Pramp: free peer-to-peer mock interviews, now owned by Exponent, with new sessions hosted on Aced Practice
• HelloInterview: AI-powered system design practice with feedback

Open-source study guides

• system-design-primer (GitHub): a massive collection of system design resources and examples
• ByteByteGo newsletter: weekly deep dives into system design topics

Managing your 45 minutes

Time management decides a lot of these rounds. My minute-by-minute breakdown:

One tip: narrate your thinking out loud, because the interviewer can't evaluate what they can't hear. Saying "I'm choosing Cassandra over PostgreSQL because our write-heavy workload benefits from Cassandra's LSM-tree storage engine" beats silently writing "Cassandra" on the whiteboard every time. Silence is your enemy in this round.

India-specific preparation tips

Prepare for Indian scale

Indian companies run at scales you won't find in a US-focused study guide. Flipkart processes millions of orders during Big Billion Days, PhonePe handles billions of UPI transactions monthly, and Zerodha absorbs a huge spike in orders every morning at market open. If you understand those numbers, you have a real edge over candidates who only practiced generic examples.

Know the Indian tech stack

Many Indian companies use the same handful of technologies, and they're worth knowing:

• Kafka is everywhere for event streaming
• Kubernetes for container orchestration (see our Docker and Kubernetes beginner's guide if you need a refresher)
• PostgreSQL and MySQL for relational data
• Redis for caching (used almost universally)
• Go and Java for backend services (more than Node.js at scale)

Cultural differences in interviews

In my experience, Indian company interviews are slightly more technical and less collaborative than FAANG ones. You might get specific implementation questions ("How would you implement the LRU cache?") alongside the high-level design, so be ready for both. I'm not sure every company follows this pattern, but I've noticed it often enough to mention.

System design interviews usually come paired with coding rounds. If you're preparing for DSA too, our DSA roadmap for placements covers how to structure that alongside system design.

Practice beats memorization

You can memorize every pattern in every textbook, watch 200 YouTube videos and read Alex Xu's books cover to cover, and none of it matters if you haven't practiced explaining your thinking out loud under time pressure. Memorizing gets you started. Practice is what gets you hired.

Do at least 10-15 mock interviews before the real ones. Record yourself and watch it back. It's painful, but you'll catch every awkward pause, every ramble and every trade-off you forgot to mention, and each round makes you sharper. Find a friend who's also preparing and take turns interviewing each other, or use Pramp (now under Exponent) or interviewing.io if nobody's around.

Learn the framework and the concepts, then practice until talking through a design feels normal.