System Design Interview Guide: Core Concepts and a Framework

System design interviews ask an open question, such as "Design a URL shortener" or "Design WhatsApp", and give you 45–60 minutes to work through it out loud. There's no single right answer. Interviewers are judging how you structure an ambiguous problem, make trade-offs and communicate, as much as what you know.

They're standard for mid-level and senior engineering roles, and increasingly common for SDE-2 candidates in India.

A framework for any question

1. Clarify requirements (5 minutes)

Ask before you draw anything:

• Functional: what must the system do? For a URL shortener: create short links, redirect, maybe custom aliases and analytics.
• Non-functional: how many users, what scale, what latency, how available, how consistent?
• Out of scope: agree what you won't cover.

2. Estimate scale (3–5 minutes)

Rough numbers guide the design: daily active users, requests per second (read vs write), data stored per day and over five years, bandwidth. Round aggressively; the point is the order of magnitude.

Example: 100 million new links a month is roughly 40 writes per second. With 100 reads per write, that's about 4,000 reads per second: read-heavy, so caching matters.

3. Define the API and data model (5 minutes)

Sketch the main endpoints (POST /links, GET /{code}) and the core tables or documents, with the access patterns that decide SQL vs NoSQL.

4. High-level design (10–15 minutes)

Draw the main components: clients, load balancer, application servers, cache, database, queues, object storage, CDN. Walk through one request end to end.

5. Deep dives (15–20 minutes)

The interviewer will push on one or two areas: how you generate unique short codes, how you shard the database, what happens when the cache fails. This is where depth shows.

6. Bottlenecks and trade-offs (5 minutes)

Name the weak points and what you'd do as load grows ten times. Mention monitoring and failure handling.

Core concepts to know

Load balancing

Spreads traffic across servers (round robin, least connections, consistent hashing). Know the difference between layer 4 and layer 7 load balancers, and that the load balancer itself needs redundancy.

Caching

Stores hot data in memory (Redis, Memcached) or at the edge (CDN). Know the patterns (cache-aside, write-through, write-back), eviction (LRU, TTL) and the hard parts: invalidation, stale reads and the "thundering herd" when a popular key expires.

Databases: SQL vs NoSQL

Relational databases give transactions, joins and strong consistency. NoSQL stores (key-value, document, wide-column) trade some of that for horizontal scale and flexible schemas. Choose based on access patterns, not fashion.

Replication

Copies of data on several machines for availability and read scaling. Leader-follower replication is common; know replication lag and what happens on failover.

Sharding (partitioning)

Splits data across machines by a shard key (user ID, hash of the key, region). A good key spreads load evenly; a bad one creates hot shards. Know consistent hashing and why resharding is painful.

Message queues and async processing

Kafka, RabbitMQ or SQS decouple producers from consumers, absorb spikes and enable retries. Use them for work that doesn't need to finish within the user's request: emails, notifications, video processing, analytics.

Consistency and the CAP theorem

During a network partition, a distributed system must choose between consistency and availability. In practice, discuss which parts of your system need strong consistency (payments, inventory) and which can be eventually consistent (likes, view counts).

Rate limiting

Protects services from abuse and overload: token bucket and sliding window algorithms, usually per user or IP, often at the API gateway.

Observability

Logs, metrics and traces, plus alerts on error rate and latency. Mentioning how you'd know the system is unhealthy is a senior signal.

Common questions to practise

1. Design a URL shortener
2. Design a rate limiter
3. Design a news feed (Twitter/X, Instagram)
4. Design a chat app (WhatsApp)
5. Design a ride-hailing service (Uber, Ola)
6. Design a video streaming platform (YouTube, Hotstar)
7. Design a payment system or UPI-style transfers
8. Design a notification service
9. Design a distributed cache
10. Design an e-commerce flash sale

Tips from interviewers

• Think out loud. Silence makes it hard to give you credit.
• Drive the conversation, but follow the interviewer's hints.
• Justify choices with trade-offs: "I'd use a cache here because reads are 100× writes; the risk is stale data, which is fine for view counts."
• Don't jump to buzzwords. Kafka and microservices need a reason.
• Practise on a whiteboard or drawing tool with a timer.

System design is usually one round among several. Prepare for the others too: Python interview questions, the STAR method for behavioural rounds, and your software engineer resume.