System Design Interview Questions and Framework

Spend the first few minutes turning the prompt into a scoped problem. List functional requirements (what users can do) and agree on which three or four are in scope. Then list non-functional requirements: scale, latency targets, availability versus consistency, durability and any regional or compliance constraints. Write them down where the interviewer can see them, and explicitly park features you are leaving out. Interviewers penalise candidates who start drawing boxes before agreeing what the system must do.

Estimate traffic, storage and bandwidth to decide whether the design needs sharding, caching or a CDN. Start from daily active users and actions per user, convert to requests per second (a day is roughly 86,400 seconds, so about 10^5), separate reads from writes, and apply a peak factor of 2–10x. Multiply object size by writes per day and retention for storage. Round aggressively; the goal is the order of magnitude, and you should say what conclusion each number leads to.

100M DAU x 10 reads/day = 1B reads/day ≈ 12K reads/s (peak ~50K/s)
100M DAU x 1 write/day  = 100M writes/day ≈ 1.2K writes/s
1.2K writes/s x 1 KB x 86,400 s ≈ 100 GB/day ≈ 36 TB/year

Write the handful of endpoints or RPCs that cover the in-scope requirements, with their key parameters and responses. Choose REST, GraphQL, gRPC or WebSockets based on the client and interaction pattern, and say why. Mention pagination (cursor-based for feeds), idempotency keys for writes that might be retried, and authentication. The API forces you to make the requirements concrete and anchors the rest of the design.

POST /v1/urls        { longUrl, customAlias? } -> { shortUrl }
GET  /{code}         -> 301/302 redirect
GET  /v1/feed?cursor=abc&limit=20 -> { items[], nextCursor }

Identify the core entities, their relationships and the main access patterns, then choose storage that fits those patterns. Relational databases suit transactional data with joins and constraints; key-value and wide-column stores suit huge volumes of simple lookups by key; document stores suit flexible, nested records; object storage holds blobs. Name the partition key early, because it determines how the data shards and which queries stay cheap.

Draw the request path end to end: clients, DNS and CDN, load balancer, stateless application services, caches, databases, queues and background workers. Walk through one write and one read request on the diagram. Keep services stateless so they scale horizontally, and put anything slow or failure-prone, such as sending notifications or processing media, behind a queue. Resist adding microservices you cannot justify.

Pick the one or two components that are hardest at the estimated scale — often the hot read path, the write fan-out, a consistency requirement or a single point of failure — and ask the interviewer which they prefer. Go into specifics: cache keys and invalidation, shard keys and rebalancing, replication mode, queue semantics and retries. This is where senior candidates separate themselves, by quantifying the bottleneck and showing how the change removes it.

Summarise the design against the requirements, then name what you traded away: consistency for availability, cost for latency, simplicity for flexibility. Cover failure modes (a cache node dies, a region goes down, a queue backs up) and how the system degrades. Mention monitoring, alerting and what you would build next with more time. Ending with a clear-eyed list of weaknesses reads as maturity, not as a flaw.

CAP says that when a network partition occurs, a distributed data store must choose between consistency (every read sees the latest write) and availability (every request gets a response). Since partitions cannot be ruled out, the real choice is how the system behaves during one. PACELC extends this: even without a partition, there is a trade-off between latency and consistency. In interviews, state which side each piece of data needs — payments lean consistent, like counts and feeds lean available.

Cache-aside (lazy loading) is the most common: the application reads the cache, falls back to the database on a miss, and fills the cache. Write-through writes to cache and database together; write-back writes to the cache and flushes later, risking loss. Discuss eviction (LRU, LFU), TTLs, invalidation on writes, and protection against thundering herds, such as request coalescing or slightly randomised TTLs. CDNs are caches for static and edge-cacheable content.

Replication copies the same data to several nodes for availability and read scaling; leader-follower replication sends writes to one node, while multi-leader and leaderless designs accept writes on several. Sharding (partitioning) splits data across nodes so each holds a subset, which scales writes and storage. Most large systems use both: each shard is replicated. Choose a shard key with high cardinality and even access to avoid hot spots.

Consistent hashing maps both keys and nodes onto a ring, and each key belongs to the next node clockwise. When a node is added or removed, only the keys in its neighbouring range move, instead of nearly all keys as with hash modulo N. Virtual nodes give each physical node many positions on the ring for smoother balance. It is used in distributed caches and databases such as Cassandra and DynamoDB-style systems.

Use a queue to decouple producers from slow or unreliable consumers, absorb traffic spikes and retry failed work: sending emails, processing uploads, fanning out notifications. A log-based stream like Kafka also retains events so multiple consumers can replay them. Discuss delivery semantics: at-least-once is the norm, so consumers must be idempotent. Ordering is usually guaranteed only within a partition.

A load balancer spreads requests across healthy instances using algorithms such as round robin, least connections or consistent hashing. Layer 4 balancers route on IP and port; layer 7 balancers understand HTTP and can route by path or header and terminate TLS. Health checks remove failed instances. Keep application servers stateless so any instance can serve any request, storing sessions in a shared store.

Choose a relational database when you need transactions across multiple rows or tables, complex queries and joins, and strong constraints; modern Postgres scales further than many candidates assume. Choose NoSQL when access patterns are simple key lookups at very high scale, the schema varies, or you need easy horizontal partitioning. Justify the choice from the access patterns you listed, not from fashion.

An operation is idempotent if performing it several times has the same effect as performing it once. Networks and queues retry, so non-idempotent writes such as charging a card can happen twice. The standard fix is an idempotency key sent by the client and stored with the result, so a retried request returns the stored response. Idempotent consumers make at-least-once delivery safe.

Remove single points of failure with redundancy at every layer: multiple instances behind load balancers, replicated databases with automatic failover, and deployment across availability zones or regions. Add timeouts, retries with exponential backoff and jitter, circuit breakers and graceful degradation. Express availability as an SLO, for example 99.9% (about 43 minutes of downtime a month), and design to it.

Requirements: create short links, redirect fast, optional custom aliases and expiry; reads vastly outnumber writes. Generate codes with base62 encoding of a unique ID from a distributed ID generator or pre-allocated ranges, which avoids collisions, or hash plus collision check. Store code → URL in a key-value store sharded by code. Serve redirects from a cache in front of the store; use 302 if you need click analytics, 301 if you want browsers to cache. Record clicks asynchronously through a queue.

Decide where it runs (API gateway or middleware) and what it keys on (user, API key, IP). Token bucket allows bursts up to the bucket size and refills at a steady rate; sliding window log is precise but memory-heavy; sliding window counter approximates it cheaply. For a distributed limiter, keep counters in Redis and update them atomically with a Lua script or INCR plus expiry. Return HTTP 429 with Retry-After and rate-limit headers, and decide whether to fail open or closed if Redis is unavailable.

The core decision is fan-out. Fan-out on write pushes each new post ID into followers' precomputed feed caches, giving fast reads but expensive writes for users with millions of followers. Fan-out on read assembles the feed at request time, cheap to write but slow to read. Most designs are hybrid: push for normal users, pull for celebrities, merged at read time. Store posts in a sharded store, feeds as lists of IDs in a cache, hydrate post details in batch, and paginate with cursors.

Clients hold persistent WebSocket connections to gateway servers; a session service maps each user to their gateway. A message is persisted first (for example in a wide-column store partitioned by conversation ID, ordered by a time-sortable message ID), then routed to recipients' gateways via a pub/sub layer, and pushed as a notification if they are offline. Track delivery and read receipts as separate events. Group chats fan out per member; very large channels are better read on demand.

Producers publish notification requests to a queue; workers look up user preferences and templates, then hand off to channel-specific senders for push (APNs/FCM), email and SMS providers. Make sends idempotent with deduplication keys, retry with backoff and a dead-letter queue, and respect rate limits and quiet hours. Track delivery status per channel. Priority queues keep urgent alerts such as one-time passwords from waiting behind marketing campaigns.

A URL frontier holds URLs to fetch, prioritised and partitioned by host so politeness rules (robots.txt, per-host rate limits) can be enforced. Fetcher workers download pages, a parser extracts links and content, and a seen-URL store — often a Bloom filter backed by a database — prevents refetching. Content hashes detect duplicate pages. Handle traps such as infinite calendars with depth limits, and store raw pages in object storage for indexing.

Partition keys across nodes with consistent hashing and replicate each key to N nodes. Tunable quorums (W writes and R reads with R + W > N) trade latency for consistency. Use vector clocks or last-write-wins timestamps to resolve conflicting writes, hinted handoff for temporary failures, Merkle trees for anti-entropy repair, and gossip for membership. On each node, an LSM tree with a write-ahead log gives fast writes.

Uploads go to object storage via pre-signed URLs; a processing pipeline triggered by a queue transcodes each video into multiple resolutions and bitrates and splits them into segments for adaptive bitrate streaming (HLS/DASH). Segments are served from a CDN, which carries almost all of the read traffic. Metadata, view counts and comments live in separate stores; counts are aggregated asynchronously. Discuss cost: storage and egress dominate.

Suggestions must return in tens of milliseconds. Precompute the top suggestions for each prefix from query logs with a batch or streaming job, and store them in a trie or a key-value map of prefix → top-k list. Serve from memory, shard by prefix, and cache popular prefixes at the edge. Clients debounce keystrokes. Filter offensive terms, and blend in personalised or trending suggestions as a separate layer.

Drivers send location updates every few seconds; store current locations in an in-memory geospatial index (geohash, S2 cells or quadtrees) partitioned by region. Matching queries nearby available drivers, ranks by ETA and offers the trip, using a lock or conditional update so a driver cannot accept two trips. Trip state is a state machine persisted in a transactional store. Location history streams to analytics; pricing and ETAs are separate services.

Split files into chunks, hash each chunk and upload only chunks the server does not already have, which gives deduplication and efficient sync. Chunks go to object storage; a metadata database tracks files, versions and the chunk list for each version. Clients learn about changes via long polling or WebSockets and download only changed chunks. Handle conflicts by keeping both versions, and use pre-signed URLs so file bytes bypass the application servers.

Correctness beats throughput. Every payment request carries an idempotency key; a payment service records intent in a relational database, calls the external processor, and records the result using a state machine (created → authorised → captured or failed). Use a double-entry ledger so money is never created or lost, reconcile against processor reports daily, and handle webhooks idempotently. Retries need timeouts and status checks so a timeout does not lead to a double charge.

LLD interviews focus on the code-level structure of one component: classes, their responsibilities, relationships, interfaces and key methods, often with working code. You are evaluated on SOLID principles, appropriate design patterns, extensibility and handling of edge cases and concurrency. Start with requirements and use cases, identify entities, define interfaces, then implement the core flow.

Entities: ParkingLot, Level, ParkingSpot (with a size or type), Vehicle (subtypes by size), Ticket and a PaymentStrategy. A spot-allocation strategy interface lets you swap nearest-spot for other policies. Ticket issuance and spot assignment must be thread-safe, for example with per-level locks or atomic compare-and-set on the spot. Pricing should be a strategy so hourly, flat or dynamic pricing can be added without changing existing classes.

Model Elevator (current floor, direction, state, request queue), ElevatorController and Request (external hall calls and internal car calls). A scheduling strategy assigns hall calls to elevators, for example the nearest elevator moving in the same direction, using the SCAN or LOOK algorithm to serve floors in order. The elevator is a state machine (idle, moving up, moving down, doors open, maintenance), which the State pattern models cleanly.

Strategy for interchangeable algorithms such as pricing or allocation, Factory for creating related objects, Observer for notifying subscribers, State for state machines, Singleton (used sparingly) for a single coordinator, Decorator for layering behaviour, and Builder for complex object construction. Explain why a pattern fits the requirement; using patterns for their own sake is a negative signal.

Combine a hash map from key to node with a doubly linked list ordered by recency: get moves the node to the head, put inserts at the head and evicts from the tail when over capacity, both O(1). For thread safety, guard operations with a lock, or shard the cache into segments with their own locks to reduce contention. Extensions include TTL expiry and a pluggable eviction policy interface.