System Design Interview Questions and Answers

Clarify requirements and scope first — functional, then non-functional (scale, latency, consistency, availability). Do a rough capacity estimate. Sketch the high-level components and the data flow between them. Define the data model and the API. Then go deep on the one or two hardest parts, and finish by naming the bottlenecks and what you would fix next. Jumping straight to boxes is the most common mistake.

Because the numbers decide the design. Ten thousand users a day and ten million a day are different systems, and an estimate tells you whether one database will do or whether you need sharding at all. Nobody expects precision — they expect you to notice that the answer depends on the order of magnitude.

Vertical means a bigger machine: simple, no code changes, and it stops at the largest machine you can buy while remaining a single point of failure. Horizontal means more machines: it scales further and survives a node failing, at the cost of load balancing, statelessness and distributed data. Start vertical, move horizontal when you must — and say that, because reaching for distributed systems too early is itself a red flag.

It distributes requests across servers, checks their health, and stops sending traffic to a failed one — which is where most of its value is. It sits in front of any horizontally scaled tier. The consequence for your design is that servers must be stateless, because the next request from the same user may land anywhere; session state goes to a shared store.

In front of anything expensive and read-heavy: query results, rendered fragments, or a CDN for static assets. What breaks is correctness — the cache can serve stale data. So every cache needs an eviction policy, a TTL, and a rule for what happens on a write: invalidate the entry, or write through it.

Choose SQL when the data is relational, the schema is stable, and you need multi-row transactions and ad-hoc queries — which covers most applications. Choose NoSQL when the access pattern is known and narrow and you need horizontal write scale or a flexible document shape. The honest answer names the access pattern first; "NoSQL because it scales" without one is the wrong answer.

Decoupling a slow or unreliable step from the request that triggered it. The request enqueues and returns immediately; a consumer processes later, retries on failure, and absorbs traffic spikes as queue depth instead of dropped requests. The costs are eventual consistency — the work is not done when the user gets their response — and the need for consumers to be idempotent, since a message can be delivered twice.

Copying data to replicas, usually one primary for writes and several read replicas. It buys read scale and a failover target. It costs replication lag: a user can write and then immediately read a replica that has not caught up, and see their own change missing. Route reads that must be fresh to the primary.

Splitting data across databases by a key, so each holds a subset. What makes it hard is everything that crosses shards: joins, transactions and unique constraints stop being cheap or possible, and a badly chosen key creates a hot shard carrying most of the traffic. Resharding later is painful, which is why the key matters more than the mechanism.

In a distributed system, when a network partition happens, you must choose between consistency and availability. The misquote is "pick two of three" — partitions are not a choice, they are a fact of networks. So the real decision is: during a partition, do you refuse requests to stay correct (CP), or serve possibly-stale data to stay up (AP)? Payments choose CP; a social feed chooses AP.

Replicas may disagree briefly but converge once writes stop propagating. It is the right trade when staleness is harmless — a view count, a feed, a search index. It is the wrong trade for an account balance or an inventory count, where reading stale data lets you sell something twice.

Two operations: create a short code for a URL, and redirect. Generate the code from a counter encoded in base62 (short, no collisions, but sequential and guessable) or from a hash with a collision check. Store the mapping in a key-value store keyed by code — the read path is a single point lookup, so it caches almost perfectly. Reads outnumber writes by orders of magnitude, so put a cache and a CDN in front and serve a 301 or 302 redirect.

A token bucket per client key: tokens refill at a fixed rate up to a cap, each request spends one, and an empty bucket returns 429 with a Retry-After header. Keep the counters in a shared store such as Redis so the limit holds across all instances rather than per server. A fixed-window counter is simpler but allows a double burst across the window boundary.

Time out every remote call — an unbounded wait turns one slow dependency into a total outage. Retry with exponential backoff and jitter, only for errors that are safe to retry. Add a circuit breaker so repeated failures stop the calls instead of queuing them. And decide the degraded behaviour in advance: cached data, a partial response, or a clear error — chosen deliberately rather than whatever happens.

An idempotent operation has the same effect whether applied once or many times. It matters because networks make retries unavoidable — a client that times out cannot know whether the request landed. Giving each request an idempotency key, and storing the result against it, is what stops a retried payment being charged twice.

Clients hold a WebSocket to a gateway so the server can push. Messages go to a service that persists them before acknowledging — an acknowledged message must survive a crash — and are then delivered to the recipient's connection, or queued for delivery on reconnect if they are offline. Store messages keyed by conversation and ordered by time, which is the only read pattern that matters, so this is a good fit for a wide-column or key-value store. Fan-out for group chat and read receipts are the parts worth going deep on.

Two strategies. Fan-out on write pushes each post into every follower's precomputed feed — reads become a single lookup, and a celebrity with ten million followers makes one write catastrophic. Fan-out on read merges the posts of everyone you follow at request time — cheap writes, expensive reads. Real systems do both: fan-out on write for ordinary accounts, and merge in the few high-follower accounts at read time.

Upload directly to object storage using a pre-signed URL, so the file never passes through your application servers. Store the metadata and the key in your database. Serve through a CDN, and generate the thumbnail sizes asynchronously via a queue rather than making the user wait. The design question underneath is: never proxy large files through your API tier.

One API that accepts a notification request and enqueues it, with per-channel workers for push, email and SMS behind it. That decoupling is the whole point: a provider outage becomes a backed-up queue rather than failed user requests. Add per-user preferences and quiet hours, deduplication so a retry does not double-send, and a dead-letter queue for what could not be delivered.

A sorted set in Redis — ZADD to update a score and ZREVRANK to read a rank — gives O(log n) updates and instant top-N. Keep the durable copy in your database and treat Redis as the read layer. The interesting follow-ups are ties, per-region boards, and how you show a user their rank when there are ten million players: a percentile is usually enough, and far cheaper than an exact position.

Detect it first — per-key metrics, not guesses. Then: cache the value close to the reader; split the key by appending a small random suffix and merging on read; or move that key to dedicated capacity. For writes, batching or a queue in front absorbs the burst. The general principle is that any scheme that keys on something with a skewed distribution will eventually produce one.

A network of edge servers that caches content near users, cutting latency and origin load. It helps enormously for static and cacheable content. It does not help for personalised or rapidly changing responses — those either bypass it or need a short TTL and careful cache keys, which is where most CDN bugs come from.

Three things together: metrics for rates, errors and duration — the numbers that page you; logs with a correlation id so one request can be followed across services; and traces to see where the time actually went. Alert on symptoms users feel, such as error rate and latency, not on causes like CPU — a CPU alert wakes you for something harmless, and misses the outage that was not CPU-bound.