System Design Interview Questions for 2026

Answer: System design is the discipline of choosing components, databases, caches, queues, load balancers, and the tradeoffs between them, so a service meets its targets for scale, latency, availability, and cost. Interviews test it separately from coding because writing features is routine while designing systems that survive traffic spikes and component failure is what separates senior engineers. Most system design interview questions are built on a dozen recurring prompts, which is why focused preparation compounds so quickly.

Answer: Functional requirements say what the system does: shorten URLs, redirect them, count clicks. Non-functional requirements say how well it must do it: latency targets, availability, consistency, scale ceilings, cost limits. The interview-relevant consequence is that missing functional requirements show up as absent boxes, while ignored non-functional requirements invalidate the whole design, which is why strong answers attach a number to every quality before drawing anything.

Answer: Scaling means adding capacity without redesigning. Vertical scaling, scale up, moves to a bigger machine, which is simple but hits hard ceilings in price and in single-node failure. Horizontal scaling, scale out, adds more machines behind a load balancer, which is how web scale is actually reached but demands stateless services and distributed data. Name both directions and their cost curves, because that tradeoff is what beginner system design interview questions actually grade.

Answer: Availability is the fraction of requests that succeed, and the nines convert directly to downtime: 99.9 percent allows about 43 minutes of failure per month, 99.99 percent about 4.3 minutes. The design consequence is what interviewers want: each extra nine means redundancy, multi-zone deployment, and accepted cost, so the target should come from business impact, not ambition. Availability targets appear in nearly all system design interview questions, so quote the downtime math without hesitating.

Answer: Latency is how long one request takes, quoted as percentiles: p50 for the typical user, p99 for the tail. Throughput is how many requests the system completes per second. They are related but distinct, and the sentence to land: a queue can raise throughput while wrecking tail latency, because work is being completed but everyone is waiting. Knowing which number users actually feel is the point of the question. That distinction between felt latency and completed work is why system design interview questions about user experience so often start here.

Answer: A load balancer distributes incoming requests across a pool of servers, turning a fleet into one logical service. It health-checks backends and stops routing to dead ones, which also makes it your failover mechanism. That dual role is why it opens so many system design interview questions: draw it early, client to load balancer to stateless servers, and note that it is also the natural home for TLS termination and coarse rate limiting.

Answer: A reverse proxy sits in front of services and handles cross-cutting work: TLS termination, compression, static file serving, routing by path. A load balancer’s core job is spreading traffic across interchangeable backends. In practice the line blurs, nginx and HAProxy do both, and cloud load balancers bundle proxy features. The safe answer: every design has one at the edge, and the difference is emphasis, distribution versus handling.

Answer: Caching keeps a copy of expensive data in a faster layer, memory instead of disk, edge instead of origin. It works because real access patterns are skewed: a small fraction of items draws most reads, the pattern behind the 80/20 rule. State the precondition and you land it: caches only pay off when data is read-heavy and tolerates slight staleness, which is why caching opens so many system design interview questions about rescuing a slow read path.

Answer: A CDN caches content on edge servers physically close to users, cutting geographic latency and offloading origin egress. Static assets are the classic use, but cacheable API responses and video segments qualify too, with TTLs and purge APIs controlling freshness. The detail that earns credit: a CDN also changes the failure model, since a well-cached site keeps serving slightly stale content straight from the edge through an origin outage. Edge behavior like this surfaces in system design interview questions more than people expect.

Answer: An index is a side structure, usually a B-tree, that lets the database find rows by a column without scanning the table, turning linear scans into logarithmic lookups. That is the difference between milliseconds and seconds at scale. The cost is the interview half: every index slows writes and eats storage, so indexes exist to serve your actual queries, not every column you might someday filter by. That write-penalty framing is the half system design interview questions on indexing actually grade.

Answer: SQL databases store structured rows under a schema and give you transactions, joins, and mature tooling. NoSQL families trade guarantees for scale and flexibility: key-value stores for lookups, document stores for varied shapes, wide-column stores for huge write volumes. The framing system design interview questions reward: pick by access pattern and consistency need, not fashion, and remember a well-indexed relational database carries most products far past their first million users.

Answer: A key-value store maps opaque keys to blobs and answers one question, get and put by key, extremely fast, which is why Redis and DynamoDB-style stores back sessions, feature flags, and caches. The trade: no joins and no rich queries, so everything must be reachable by the key you chose. That constraint is the lesson: with key-value stores, data modeling means predicting access patterns before writing a line of code.

Answer: A document store saves self-contained JSON-like documents, so fields can vary per record without migrations, which fits catalogs, user profiles, and content systems. It trades schema enforcement for flexibility and often pays with weaker cross-document transactions that the application must compensate for. The sharp sentence: documents model aggregates read as a whole, and the moment you query across documents by arbitrary fields, indexes or a different database enter the design.

Answer: Normalization removes duplicated data so writes stay consistent; denormalization deliberately copies data so reads touch fewer places. At scale, joins across sharded datasets become brutal, so designs copy and accept the cost: update logic must now keep the copies consistent, usually through events or scheduled reconciliation. This trade is one of the most common threads in system design interview questions, because it converts a database purity debate into a concrete read-versus-write budget.

Answer: An object store, S3 and its relatives, keeps blobs behind HTTP APIs with flat keys, effectively unlimited scale, and durability through replication, at prices disk arrays cannot match. It is the default home for images, video, backups, and data lake files, while a database holds the metadata rather than the blobs themselves. The boundary to state: object stores are durable and cheap but wrong for random small reads, so they are storage, not a query layer.

Answer: Replication keeps copies of the same data on multiple nodes for durability and read scale. Synchronous replication waits for every copy, which is safe but slow, while asynchronous returns fast and risks losing the last writes if the primary dies. The problem it creates is divergence: replicas drift under load and readers see stale rows. Naming that lag, and deciding who tolerates it, is what interviewers listen for here. Replica lag, met in this answer, returns as the villain of system design interview questions on read routing and stale reads.

Answer: Sharding splits data horizontally across nodes by a key such as user ID or region, so no single machine holds everything. It is the last big lever: it buys write throughput and dataset size beyond any single box, and charges for it with lost cross-shard transactions, harder joins, and painful resharding when the key ages badly. In system design interview questions, reach for sharding after replicas and caching, and say out loud why the earlier levers ran out.

Answer: A message queue holds work between producers and consumers, so a request can be accepted quickly and processed later. It buys smoothing against spikes, retry semantics for failed work, and independence between services that would otherwise call each other synchronously. The design consequence worth stating unprompted: anything that does not need to happen inside the request, emails, thumbnails, analytics, belongs on a queue, not in the critical path. Queues are the component system design interview questions reach for the moment a prompt hides a spike behind a friendly feature list.

Answer: Stateless services keep no per-client memory between requests, so any instance can serve any request. That property makes horizontal scaling trivial, add instances behind the load balancer, and makes failover boring: kill a node and nothing is lost. State belongs outside, sessions in Redis, files in object storage, data in the database. Statelessness is the hinge most system design interview questions turn on once traffic doubles, so make the follow-through automatic.

Answer: An idempotent operation produces the same result no matter how many times it runs, which is exactly what retries require. Networks fail after a request has landed, so clients retry, and a non-idempotent payment endpoint turns one purchase into three charges. The standard fix is idempotency keys: the client sends a unique token and the server deduplicates on it. Expect the follow-up about where the dedup store lives and how long keys are retained. This is also why system design interview questions about payments almost always detour through retry semantics.

Answer: Rate limiting caps how many requests a client can make in a window, protecting shared capacity: the database, downstream APIs, and other tenants. It is an availability tool as much as a fairness tool, because one runaway script should degrade one customer, not the platform. Early system design interview questions use rate limiting to test whether you think about abuse and failure rather than the happy path, so mention thresholds, rejection behavior, and the headers that tell clients where they stand.

Answer: CAP says that during a network partition a distributed store must choose: stay available and serve possibly stale data, or stay strictly consistent and refuse some requests. Partition tolerance is not optional since networks do partition, so the real choice is AP versus CP during failure. The nuance that lands: CAP is about partitions, not everyday tradeoffs, and under normal operation most systems offer both, which is exactly the layer system design interview questions at this level are testing.

Answer: Eventual consistency lets replicas diverge briefly, with the guarantee they converge once writes settle; it is the model behind DNS, caches, and most multi-region designs. It is acceptable when users cannot act harmfully on the stale slice: like counts, timelines, search indexes. It is unacceptable for account balances and inventory, where overselling costs real money. Volunteering one example from each side is the entire expected answer, because system design interview questions on consistency are really boundary-drawing exercises.

Answer: The honest default is a modular monolith: one deployable with clean internal boundaries, keeping transactions local and operations simple. Microservices buy independent scaling and team autonomy, and charge for it in network failure modes, distributed transactions, and heavy operational tooling. The split rule that answers most system design interview questions on this topic: extract a service when a component has genuinely different scaling or release needs, never for fashion.

Answer: Scale up first when the workload fits one beefy machine: it avoids distributed complexity entirely, keeps transactions local, and a 10x bigger box is far cheaper than a distributed rewrite. Relational databases especially reward vertical headroom before anyone mentions sharding. Scale out once you exceed single-machine ceilings or need failure isolation. The mature framing: scale up buys time, scale out buys ceilings, and good designs delay the second until the first is exhausted.

Answer: A back-of-envelope estimate turns the prompt’s volumes into peak QPS, storage growth, and bandwidth before anything is drawn, using arithmetic you do aloud: daily volume divided by 86,400 seconds, times a peak factor around 3. It matters because the numbers pick the architecture: 50 QPS is a laptop, 50,000 QPS means caches and sharding. System design interview questions open here because estimation errors propagate: misjudge the scale and every later choice inherits the mistake.

Answer: QPS, queries or requests per second, is the capacity unit everything else hangs off. The conversion: daily volume divided by 86,400 gives the average, and multiplying by a peak factor, 2 to 5 depending on traffic shape, gives what you actually design for. Reads and writes convert separately because they stress different layers: 10 million reads and 100 thousand writes a day is a read problem, and that ratio decides where caches and replicas go.

Answer: A hot key is one cache entry or partition absorbing disproportionate traffic, a celebrity user, a viral product, a popular config value, and it defeats horizontal scaling because the load is concentrated, not spread. First fixes: replicate the hot entry across cache nodes, shorten its TTL, or pin it in process memory. Hot spots recur in system design interview questions as the follow-up that tests whether “we sharded it” survives contact with skewed data.

Answer: A read replica is a near-live copy of the primary database that serves read-only queries, multiplying read capacity and adding a failover candidate. The catch is lag: asynchronous replication means a replica can run seconds behind, so a user who writes then immediately reads may see stale data. Route latency-sensitive reads to the primary and everything else to replicas. Mentioning read-your-own-writes handling is what turns the definition into a design answer. Because read replicas carry most production read paths, system design interview questions revisit this component at every seniority level.

Answer: A TTL, time to live, is the expiration stamped on cached data so stale copies die without anyone deleting them by hand. It bounds how wrong the cache can be: a one-hour TTL means at most one hour of staleness. Every entry needs one, because TTL-less entries are how caches fill with data nobody trusts. This small knob runs through system design interview questions because it is the main lever balancing freshness against origin load.

Answer: A connection pool keeps a set of database connections open and lends them to request handlers, because opening a connection per request costs a TCP handshake, authentication, and memory that dwarf the query itself. The design point: pools cap concurrency, so a pool of 100 turns 1,000 arriving requests into 100 database sessions with the rest queued. Sizing is the interview angle: too small starves throughput, too big overwhelms the database.

Answer: Sessions move out of the app tier once you scale horizontally. Sticky sessions bind each user to one server and sabotage failover, so the standard design keeps session state in a shared fast store such as Redis, with the cookie holding only an opaque session ID. The payoff: any instance can serve any request, and losing an app server costs nothing. Local in-memory sessions are the beginner answer interviewers flag immediately. Session placement doubles as a statelessness probe, which is why system design interview questions favor it as an early round.

Answer: Failover is the automatic switch to a standby when the active component dies: load balancers pull dead servers from rotation, databases promote replicas. The costs deserve naming: asynchronous replicas can lose the most recent writes on promotion, and automatic failover can misfire during a network partition, leaving two nodes that both believe they are primary. That split-brain scenario, and quorum as the defense, is the follow-up this question is built to reach.

Answer: A single point of failure is any component whose death takes the service with it: one database node, one cache instance, one region, one DNS provider. The design habit to demonstrate is walking the diagram box by box and saying what happens when each dies; redundancy requirements then fall out naturally instead of being bolted on. Most entry-level system design interview questions are secretly this question, and the pass condition is having no component you cannot afford to lose.

Answer: A health check is a small endpoint that a load balancer or orchestrator polls to decide whether an instance deserves traffic. Liveness asks whether the process is up; readiness asks whether it can actually serve, dependencies included. The nuance worth stating: a deep check that touches the database on every probe can take out an entire fleet when the database blips, so keep liveness shallow and reserve the honest dependency check for readiness. This distinction recurs in system design interview questions for platform roles.

Answer: An API gateway is the single front door for clients: it routes to internal services and centralizes cross-cutting concerns, authentication, rate limiting, TLS, response shaping, and aggregation of calls. It earns its place when many services would each otherwise reimplement those concerns, and it costs an extra hop plus a component to operate. Keep it thin: gateways route and enforce policy, while business logic lives in the services behind them.

Answer: Observability is the property that you can answer “why is it misbehaving” from the system’s outputs: metrics for trends and alerts, logs for specifics, traces for a request’s path across services. In a design round the expectation is one solid paragraph: what you measure, latency percentiles and error rate per endpoint, where traces begin, and what pages a human at 3 a.m. Designs without a monitoring story read as designs that have never been operated.

Answer: Graceful degradation is planned partial failure: when a dependency is down, the service drops features instead of dying, serving cached or default recommendations instead of personalized ones, queueing emails instead of sending instantly. It requires deciding in advance which features are core and which are optional, and wiring fallbacks for the optional ones. It closes this tier because every scenario question ahead is graceful degradation applied to one specific symptom.

Answer: Start from stated volumes: 2 million uploads a day, 500 KB average, reads outnumbering writes 20 to 1. Writes: 2M divided by 86,400 is about 23 QPS, roughly 70 at peak. Storage: 2M times 500 KB is 1 TB per day, about 365 TB a year, and near 1 PB with three-copy replication. Reads: 460 QPS average, around 1,400 at peak, and 460 times 500 KB is about 230 MB/s of egress. Those four numbers argue for object storage, a CDN, and asynchronous thumbnailing. Working the units aloud is exactly what system design interview questions at this stage grade.

Answer: Bandwidth is QPS times average response size. At 1,400 peak QPS serving 500 KB images, egress is about 700 MB/s, roughly 5.6 Gbps sustained. Two thresholds then decide: when egress exceeds what one region can comfortably push, and when users sit far from the origin, a CDN stops being optional. Also compute the cacheable fraction: static assets typically draw 80 to 90 percent of requests, so the edge absorbs them and origin sees a sliver. Quoting both the Gbps figure and the hit fraction makes the decision defensible instead of decorative. CDN or no CDN is one of the cleanest forks system design interview questions ask you to defend with a single number.

Answer: An L4 balancer routes on IP addresses and ports, inside the network path, cheaply and without reading the request, so it handles enormous connection volumes and raw TCP. An L7 balancer parses HTTP: routing by path or header, TLS termination, header injection, and smarter placement, like sending all v2 API traffic to new backends. The tradeoff is parsing cost, so large architectures stack them: L4 for volume at the edge, L7 for decisions near the services. Saying where each sits in that stack is the expected depth.

Answer: Naive hashing, key mod N, remaps nearly every key when N changes, catastrophic when cache nodes join or leave. Consistent hashing places nodes and keys on a ring: each key belongs to the next node clockwise, so adding or removing a node reassigns only the neighboring arc, about 1/N of keys. Virtual nodes smooth the distribution and let uneven hardware take uneven shares. Distributed caches, Cassandra, and DynamoDB are built on it. The sentence system design interview questions listen for: consistent hashing makes scale-out events boring, and that is precisely its job.

Answer: Cache-aside puts the application in charge. On read: check the cache, and on a miss, read the database, populate the cache with a TTL, return. On write: update the database first, then invalidate or update the cached key. It is the default pattern because the cache stays a pure optimization: the system remains correct with the cache cold or dead. The depth-earning details: a race can let a stale write repopulate the cache after invalidation, and the TTL bounds how long that staleness survives. Most system design interview questions about caching start here, so narrate the read and write paths separately.

Answer: Write-through updates cache and database synchronously on every write: reads are always warm, writes slower, and nothing evaporates if the cache dies. Write-behind acknowledges the write at the cache and flushes to the database later, which is fast but loses unflushed data if the cache node fails. Write-around skips the cache on writes and caches only on read, keeping churned data from evicting hot entries. Choose by workload: write-through for correctness-sensitive reads, write-around for write-heavy traffic full of cold data. Pricing each write path in latency and risk is the habit system design interview questions on caching are built to find.

Answer: Invalidation is the hard part because there is no global clock across layers. Work the ladder: event-driven invalidation, where the write path publishes a purge that the cache layer consumes; versioned keys, where each write creates key-v2 and the old version dies by TTL, sidestepping deletion races entirely; and CDN purge APIs for edge copies. Stale-while-revalidate softens the miss window by serving the old value while refreshing. The honest sentence: some staleness is unavoidable, so bound it with TTLs and choose invalidation granularity, per key, per user, per prefix, deliberately. Naming the bound out loud is what the invalidation half of system design interview questions is really grading.

Answer: A stampede occurs when a hot key expires and hundreds of concurrent misses fire the identical expensive query at the database. Defenses, in order of preference: request coalescing, a single-flight lock where one request recomputes while others wait or serve a stale copy; probabilistic early expiry, where each request refreshes slightly before TTL with small probability so expiration diffuses; and jittered TTLs so mass-simultaneous expiry cannot happen. Combine stale-while-revalidate with a lock and the database never sees the herd. Cache stampedes are fixtures of system design interview questions because they test whether you cache for failures, not just for speed.

Answer: The CDN serves from the edge nearest the requester: on a miss it fetches from origin, caches per Cache-Control headers, and subsequent hits never reach you. Freshness is governed by max-age, with s-max-age for shared caches and revalidation via ETag or Last-Modified returning cheap 304s for unchanged content. Purging is explicit: push APIs invalidate by URL or cache tag globally within seconds. The design trap worth naming: cache keys usually ignore cookies but honor Vary, so varying on the wrong header quietly destroys the hit rate. Header-level traps like Vary are how system design interview questions separate operators from library users.

Answer: Replicas lag because asynchronous replication applies changes after the primary has already acknowledged, seconds behind under heavy write load. Route reads by tolerance: strongly consistent reads to the primary, everything else to replicas. For read-your-own-writes, either read the primary briefly after a write, or track the user’s last write position and hold the read until the replica reaches it, the token approach in Redis and MongoDB drivers. Monitor lag itself with alerts, because it degrades silently. This routing split is one of the most probed mechanisms in system design interview questions about scaling reads.

Answer: The shard key decides which node owns each row, and the choice is close to irreversible. Pick for high cardinality and alignment with the dominant access pattern: user ID for per-user data, so one user’s reads and writes land on one shard. Even distribution matters as much as access: keys correlated with time or geography create hot shards that no replica can relieve. Compound keys and a directory lookup table are the escape hatches when a single column cannot serve both goals. In system design interview questions, stating “I derive the key from the query patterns, and here is the query that must cross shards” is the senior move.

Answer: A bad key shows up as uneven load, some nodes pegged while neighbors idle, or as queries fanning to every shard because the key was missing from the predicate. Escalate in order: cache the hot entities, move them to their own shard, then reshard. Live resharding follows one pattern everywhere: dual-write to old and new layouts, backfill history in background batches, verify with counts and checksums, then flip reads shard by shard with a rollback path. Iterative hashing or a directory service prevents repeating the mistake at the next growth step.

Answer: Two-phase commit gets multiple nodes to agree atomically: a coordinator asks every participant to prepare, and once all confirm, commits them all together. The costs explain its unpopularity: the coordinator is a blocking single point for the duration, a crashed participant holds its locks indefinitely, and each additional participant widens the failure window. Modern designs prefer sagas, sequences of local transactions with compensating actions, or accepted temporary inconsistency repaired by reconciliation. That blocking property is the sentence system design interview questions on atomicity hunt for.

Answer: A distributed lock is a mutually exclusive flag in shared storage: Redis with SET key value NX EX, or etcd and ZooKeeper with session leases. The failure modes are the interview content: a holder can pause through garbage collection or a network blip and wake after its lease expired, while another process already owns the lock, so exclusivity silently breaks. Defenses: short leases with renewal loops, and fencing tokens, monotonically increasing grant numbers that storage verifies so stale holders cannot write. Never rest correctness on locks alone; make a double-execution survivable. Lock races are a senior-loop staple of system design interview questions because they expose who has actually debugged one.

Answer: An append-only log such as Kafka stores events immutably in ordered partitions; producers append, consumers read at their own offset, and nothing is deleted on read. That single design yields ordering within a partition, replay from any point, which is how new consumers rebuild state from history, and natural buffering between producers and consumers. Partitions are the parallelism unit, and keying messages by entity ID keeps each entity’s events ordered on one partition. The trade to name aloud: partition count caps consumer parallelism and is painful to change after the fact.

Answer: Choose by what consumers need. A queue in the SQS style deletes messages on delivery: ideal for task distribution, sending emails, resizing images, where each job wants exactly one worker and history has no value. A log in the Kafka style retains events for days or forever: it fits fan-out to multiple independent consumers, event sourcing, and analytics, where replay is the point. Ordering, latency, and failure semantics differ too, so decide from the access pattern. This fork is one of those system design interview questions that looks like trivia but quietly decides the whole architecture.

Answer: Assume double delivery, because redelivery after crashes and timeouts is normal operation, not an anomaly. The standard pattern: carry a unique message ID and record processed IDs in a dedup store that lives in the same database as the effect, so the check and the write commit atomically. Alternatives: natural idempotence through upserts and conditional writes, or versioned effects where reapplying an old event is a no-op. The sentence to say: dedup belongs with the state it protects, not in the queue itself, because the queue cannot know what your side effects mean. Pair this with the idempotency-key pattern and system design interview questions on delivery semantics collapse into one reusable story.

Answer: Backpressure is the feedback that tells producers to slow down when consumers fall behind. Push systems need explicit mechanisms: bounded queues that reject or shed when full, TCP-level backpressure, or load shedding at the edge with priority tiers so critical requests survive while batch work waits. Pull systems, consumers reading a queue or log at their own pace, get backpressure for free, which is a core argument for that shape. The line to deliver: an unbounded queue is not elasticity, it is a delayed outage, so every push path needs a named overflow behavior.

Answer: Offset pagination, LIMIT 50 OFFSET 10000, makes the database walk and discard ten thousand rows, so deep pages get slower while concurrent inserts shuffle results between fetches. Cursor pagination encodes the last seen value, an ID or timestamp, into an opaque token and seeks directly with an indexed predicate: page 1000 costs what page 1 costs, and results stay stable. The costs are real: no jumping to arbitrary pages, and you need a deterministic, indexed sort key. Nearly every modern API chose cursors, and explaining why scores in system design interview questions about feeds and listings.

Answer: Two architectures meet here. Fan-out on write pushes each new post into every follower’s precomputed feed at posting time: reads become one indexed lookup, but a celebrity post triggers millions of writes and hot-partition pain. Fan-out on read assembles the feed at request time by merging followed users’ posts: writes stay trivial while reads grow expensive. Real systems hybridize: precompute for ordinary users, merge on read for celebrities, with ranking layered on top. This tradeoff is one of the most repeated system design interview questions because it exposes read-write economics inside a single familiar prompt.

Answer: The core decision is how short codes map to URLs. A counter encoded in base62 gives short, collision-free codes, at the cost of a scaling counter and guessable URLs. Hashing the long URL and truncating avoids coordination but needs collision checks and yields longer codes. Random codes with a uniqueness check sit between. Around the core: cache hot redirects, choose 301 versus 302 based on whether analytics matter, and store the mapping in a key-value or wide-column store, since lookups are by code alone. URL shortener system design interview questions persist because every one of these choices teaches a tradeoff.

Answer: A token bucket keeps a counter of tokens refilled at rate r up to capacity b; each request consumes one token, and an empty bucket means reject or queue. The two parameters are the entire design: rate sets sustained throughput, capacity sets tolerated burst, which is why token buckets handle real spiky traffic better than plain counters. Distributed versions shard buckets by user into Redis and make check-and-decrement atomic with a small Lua script.

# refill then admit, in one atomic step
tokens = min(capacity, tokens + elapsed * refill_rate)
allowed = tokens >= 1
tokens  = tokens - allowed

Sketching that refill math within a minute is what system design interview questions on rate limiting expect.

Answer: A fixed window counter is cheap but permits a double burst across the boundary: 100 requests at 11:59 and 100 more at 12:00. A sliding window log stores each request’s timestamp and counts the true trailing window: exact, but memory-hungry at volume. The sliding window counter, a weighted blend of the current and previous buckets, approximates the log at counter cost and is the usual production compromise. Naming the boundary-burst flaw and the log’s memory cost is exactly what the question grades, and it is the detail system design interview questions on rate limiting extract.

Answer: In layers, each with a purpose. Client-side limits only advise and are trivially bypassed, so they never count as protection. Edge or gateway limiting guards the whole fleet and takes coarse per-IP and per-key caps. Service-level limiting protects one dependency, the database or a paid third party, with budgets assigned per caller. Infrastructure throttles, connection caps and worker pool bounds, are the backstop. Distributed limiting needs shared state, so stick users to limiter nodes with consistent hashing or accept a Redis round trip. This placement conversation is where system design interview questions about rate limiting go after the algorithm.

Answer: Counters must be atomic, so they live in an in-memory store: INCR plus EXPIRE in Redis, executed as one atomic Lua block. At high rates a single Redis holding every bucket becomes both bottleneck and failure domain, so shard counters by key across nodes, and for very hot keys keep local in-process counters that synchronize to the shared store at intervals, accepting slight overcount. Persisting violations for analytics happens asynchronously, never inside the reject path. Losing a counter window is acceptable, which is why counter replication can be relaxed while the data behind it cannot. The asymmetry, throwaway counters guarding durable data, is the insight system design interview questions on rate limiting are fishing for.

Answer: WebSocket connections are long-lived and stateful, which breaks naive horizontal scaling, so chat designs deploy dedicated connection servers, each holding on the order of 100 thousand sockets, with a routing layer that knows which server owns which user. Messages flow through a queue or log that decouples senders from recipients; connection servers push to online users, while offline users sync from durable storage on reconnect. Load balancers need long idle timeouts, and deploys must drain connections gracefully. The number that reframes the problem: a handful of connection servers carries a million concurrent users, so this is a routing problem, not a capacity one, which is the frame chat system design interview questions want.

Answer: Order by server-assigned sequence numbers per conversation, never client timestamps, because phone clocks lie: each message takes the next sequence for its thread and clients render in that order. Delivery states form a ladder, sent to server, delivered to device, read, with each transition published as an event every other device consumes. Out-of-order arrival is normal, so clients buffer briefly on gaps instead of erroring. Group chats multiply the fan-out, which is exactly where sequence-per-conversation pays for itself. Chat system design interview questions push here because ordering plus receipts exercises queues, storage, and device sync inside one prompt.

Answer: An inverted index maps each term to the sorted list of documents containing it, the structure beneath Elasticsearch and Lucene. Indexing tokenizes documents and appends postings; search intersects the postings lists for the query terms, then ranks with scoring such as BM25. Near-real-time behavior comes from writing new documents into small in-memory segments that become searchable after a refresh interval, merging in the background, which is why search trails writes by seconds. Name the two expensive operations: heavy write volume fighting indexing throughput, and deep pagination or broad aggregations hammering the cluster.

Answer: Wide-column stores like Cassandra win when writes dominate, datasets run to terabytes and beyond, and every access happens by known keys: time series, telemetry, message histories, denormalized per-user records. You model tables around specific queries, one table per access pattern, because arbitrary joins and ad hoc queries are precisely what you surrender. Relational remains right for transactional integrity and flexible querying; document stores for varied read-whole aggregates at moderate scale. The decision sentence that scores in system design interview questions: write down your five hottest queries first, and the storage choice usually falls out of them.

Answer: One account with millions of followers turns fan-out on write into millions of insertions per post, stalling the posting path and hammering one shard. The fix is a hybrid: ordinary users’ posts fan out immediately, while celebrity posts merge into feeds at read time or get distributed by a background job on a delay. The same entity is hot in storage too, so its rows replicate across cache nodes and its write path gets aggregated. Stating the threshold logic, live fan-out below N followers, merge above, plus the resulting tail-latency asymmetry, is the expected depth. Skew like this is why system design interview questions distrust any design that assumes uniform traffic.

Answer: A write-ahead log records each modification to an append-only file before the change touches real data pages, which is how engines keep crash safety: after a crash, replay the log to restore committed state. The same log doubles as replication, replicas stream it, and as point-in-time recovery, restore to any offset. One mechanism explains PostgreSQL’s WAL, MySQL’s binlog, and Kafka’s own core design. Interviewers like this question because it ties durability, replication, and recovery to a single idea you can state in two sentences.

Answer: Nodes prove liveness by renewing a lease, a timed grant held in etcd, ZooKeeper, or Redis, and the cluster treats an expired lease as a dead owner whose work may be reassigned. The design problem is time: a process paused by garbage collection can wake after its lease expired, still believing it owns the work. Leases therefore pair with fencing tokens, monotonically increasing grant numbers that storage checks before accepting writes. Tune lease length between detection speed and false evictions during pauses. Describing the pause-and-wake race is the depth this question seeks.

Answer: Consensus protocols like Raft elect one leader by majority vote: candidates request votes for a term, each node votes at most once per term, and a majority makes you leader; higher term numbers make stale leaders self-identify and step down. The majority is the safety property: only one side of a partition can gather it, which prevents split-brain at the price of unavailability when no majority exists. In practice etcd or ZooKeeper supply this off the shelf, and most systems should consume election rather than implement it. Explaining why a majority, not merely any response, is required answers the standing follow-up, and the same election story recurs in system design interview questions wherever two nodes must not both write.

Answer: With replication factor N, quorum systems expose two dials: writes acknowledged by W replicas, reads served from R, and requiring R plus W greater than N guarantees every read overlaps the newest write. Write-all-read-one is fast to read, slow to write; write-one-read-all inverts it; N equals 3 with R and W at 2 is the common middle. The catch to volunteer: quorums deliver the latest value but not automatic conflict resolution, so concurrent writes still need last-write-wins or versioning. This dial conversation is a fixture of system design interview questions on consistency.

Answer: Version at the API surface first, in the path or a header, and keep old versions alive past every client’s upgrade window. Inside payloads, evolve compatibly: add optional fields, never repurpose existing ones, and treat removal as a version bump. For schemas and events, the same additive-first rule applies: ship the expansion, migrate consumers, clean up later. Contract tests running against every supported version catch breakage before clients do. The sentence that earns credit: deprecation is a process with dates and dashboards counting who still calls v1, not a changelog entry. Compatibility discipline shows up in system design interview questions as a governance test: who breaks, who gets warned, and who pays.

Answer: Expand-contract splits a risky migration into independently rollback-able steps. Expand: add the new column or table alongside the old, with the application keeping both in sync. Migrate: backfill historical rows in batches, verify with counts and checksums, and prove parity with dual or shadow reads. Contract: flip reads to the new layout, then drop the old structure in a later deploy once metrics confirm nothing needs it. Every step is reversible, which is the property that makes zero-downtime migrations tractable at all. Expand-contract is the standard answer to system design interview questions about changing schema under live traffic.

Answer: The client generates a UUID per logical operation and sends it unchanged on every retry. The server stores the key together with the result, ideally in the same transaction as the effect, so check-and-execute is atomic; a replay returns the stored response without re-running anything. The details that matter: keys need a retention window, 24 to 72 hours is typical, in-flight requests need interim responses so concurrent duplicates cannot double-execute, and the stored response must be byte-stable across replays. Any POST with side effects, payments above all, deserves this from day one.

Answer: Three pieces do the work: DNS or anycast routing steers each user to the nearest healthy region, a CDN absorbs static and cacheable traffic at the edge, and data follows with region-local reads. For writes, choose honestly between models: a single primary region keeps consistency simple and accepts cross-ocean write latency, while multi-region active-active cuts latency for everyone and pays with conflict resolution, CRDTs or last-write-wins. Reference data replicates everywhere, and user-partitioned data can home-region by owner. Geo system design interview questions are really latency-versus-consistency questions wearing a geography costume.

Answer: Coherence across layers comes from a TTL ladder plus explicit invalidation. Give layers descending freshness: seconds at the browser, minutes at the CDN, longer in the application cache, so an origin purge propagates outward as each layer revalidates, with stale-while-revalidate hiding the refresh window. On writes, publish the affected cache keys and purge CDN and application layers together, so no layer serves what another already forgot. The discipline that makes it work: one team owns the TTL policy table, because scattered TTLs are how mysterious staleness happens. Layered coherence appears in system design interview questions more often than any single eviction algorithm.

Answer: Little’s law, concurrency equals throughput times latency, converts targets into pool sizes. To sustain 1,000 QPS against a 50 millisecond average downstream latency, a service needs about 50 concurrent in-flight calls, so a pool near 50 saturates; extra threads beyond that only deepen the queue. Size each dependency’s pool with the same law, add headroom for bursts, then verify under load, because real latency distributions have p99 tails that the average hides. Stating the formula and plugging in real numbers is the whole expected answer, and it separates tuned designs from guessed ones.

Answer: Triage in cost order, and say the order. First, measure: p99, error rate, and saturation per component, so you fix the binding constraint instead of guessing. Second, cache: raising hit rates and adding cache layers is the cheapest capacity that exists, and most read-heavy systems have headroom hiding there. Third, database headroom: connection counts, slow queries, replica capacity, because this is where 10x usually lands. Fourth, move work off the request path onto queues. Fifth, and only now, shard or add a region, the expensive levers. State the capacity math, 10x traffic is rarely 10x database load once caches scale, and commit to load testing at the new peak. Scenario system design interview questions grade the sequence and the reasoning, not the heroics.

Answer: Reconstruct the failure chain, then fix both directions. What happened: a popular key expired, every request missed simultaneously, the database absorbed thousands of identical rebuild queries, and cascading timeouts amplified the spike. Immediate mitigation: put a single-flight lock on hot key rebuilds and enable stale-while-revalidate so expired values still serve while one request refreshes; if the cache is empty, restore a snapshot or warm the top keys before reopening traffic. Durable fixes: jittered TTLs, probabilistic early refresh, per-key rebuild locks, and stampede drills in staging. The interview point is the ordering, stabilize, then prevent, and speaking that sequence is what scenario system design interview questions around caching reward.

Answer: Stabilize the blast radius first: cap the dependency with timeouts shorter than your own latency SLO, size thread and connection pools so hung calls cannot exhaust them, and add a circuit breaker that fails fast once error rates cross threshold, with a fallback, queue the payment for retry, show a cached status, degrade the feature. Then move the call off the request path where the product allows: accept and reconcile asynchronously, since payments tolerate that better than waiting users do. Only after containment, escalate to the vendor or add a second provider. Naming pool exhaustion as the propagation mechanism is what separates experienced answers in system design interview questions about slow dependencies.

Answer: Diagnose before redistributing: confirm the skew with per-shard QPS and per-key access counts, because “one shard is slow” is almost always “one key is hot.” Mitigations in escalation order: cache the hot entities aggressively with short TTLs and stale-while-revalidate; add read replicas or replicated cache copies for the hot range; batch or queue writes to it. Structural fixes follow: salt the key, appending a suffix so one hot key spreads across several, or move celebrities to a merge-on-read path if feeds are involved. Close with the design lesson: skew is the normal case, and capacity plans must assume it. Hot partition system design interview questions test whether your even-distribution claim survives contact with real data.

Answer: Quantify first: 300 ms is physics, fiber speed of light, so no tuning of the existing path removes it; the fix moves compute or hides latency. Restructure in tiers: put a CDN and regional caches in front of static and cacheable reads immediately; deploy regional application tiers reading from region-local replicas; then choose the write model deliberately, a single primary region with cross-ocean writes staying rare and consistent, or active-active with conflict resolution for latency-critical writes. User-homed data, each user’s writes landing in their home region with async replication outward, is the common compromise. Cross-region system design interview questions want you to separate what must be consistent from what only feels like it must be.

Answer: Correlate before optimizing: diff the deploy for new queries, changed indexes, or altered ORM behavior, then confirm with the database itself. Order: slow query log and pg_stat_statements or performance schema for the top offenders; check for sequential scans on tables the feature touches; watch the buffer or cache hit ratio collapsing, which turns cheap pages into disk reads. Quick mitigations: kill or deprioritize the offending query, add the missing index concurrently, or roll the feature back while the real fix lands. Prevent: query review and load tests with production-shaped data before launch. Naming the evidence that would confirm each hypothesis is the graded habit of scenario system design interview questions.

Answer: Establish scope: check which replicas trail and by how much, then confirm users are on the lagging path by comparing what the primary holds against what the replica served. Immediate relief: route latency-sensitive reads, the author’s own feed above all, back to the primary; kill expensive reporting queries starving the replication appliers; add replica capacity if lag tracks load. Structural fixes: batch the write floods that bloat the log, raise applier parallelism, and alert on lag against a budget, under 5 seconds, say. Then design the apology: read-your-own-writes tokens so an author never sees their own post missing. The grade goes to the routing split, not to blaming the replicator. Most replica-lag system design interview questions are this scenario wearing different clothes, so rehearse the whole sequence.

Answer: Work the memory before the workload: INFO memory for fragmentation and eviction counts, then attribute bytes with key sampling, since one TTL-less key family usually dominates. Classify what you find: entries missing TTLs, oversized values that belong in object storage, or genuine capacity exhaustion from growth. Immediate levers: set maxmemory-policy deliberately, allkeys-lru or volatile-lru, add TTLs to the offending family, raise memory. Structural: split hot and cold data across instances, compress values, and alert on memory as a percent of maxmemory before users feel evictions. The interview point: evictions are a symptom with an owner, and finding the owning key family is the entire diagnostic. Attribution before action is the reflex system design interview questions on cache incidents reward.

Answer: Identify what the depth threatens: consumer lag becomes staleness, and unbounded broker memory or disk becomes an outage, so bound the queue now. Stabilize: scale consumers horizontally if the work parallelizes, raise consumer concurrency, and hunt the poison message causing retry loops, dead-letter it. If producers genuinely outpace capacity, shed or degrade at the edge: drop or compact low-value events, batch high-volume producers, and apply backpressure so callers feel delay instead of the broker dying. Alert on consumer lag against a processing-rate SLO, not depth alone. The sentence that lands: a queue buys smoothing, never throughput, so growing depth means a capacity or poison-message problem, the exact fork scenario system design interview questions dangle.

Answer: This is a stampede with a trigger you controlled. Immediate play: rate-limit cache fills so the database degrades gracefully instead of dying, and pre-walk the top keys, ranked by access logs, through the application before reopening full traffic. Prevention: never flush everything at once, expire in staged batches; keep a persistent cache layer or snapshot to restore from; make hot keys stampede-proof with rebuild locks and stale-while-revalidate so a cold cache slows reads instead of doubling database load. Add a dry-run line to the runbook: every cache-affecting operation states what fraction of traffic the origin must absorb. The graded instinct is treating the cache as a dependency with its own failure mode.

Answer: Trace the payment path for the missing dedup boundary: a client retried after a timeout and some layer executed twice, so find which hop lacked the key, gateway, service, or processor call. Containment: reconcile against the processor’s transaction list, refund duplicates, and add a dedup check on the idempotency key before any money moves. Durable fix: client-generated idempotency keys per logical operation, stored atomically with the result, concurrent duplicates receiving the in-flight response; make the processor call idempotent too, since your dedup store can lose a race with a crash. Say the principle aloud: retries are normal traffic, and every non-idempotent operation is a latent double-charge. This is among the most consequential scenario system design interview questions because real money is the stake.

Answer: Bisect along the request path, because unchanged CPU points at waiting rather than computing. Order: compare p99 against p50, a widening tail with a stable median means added variance, GC pauses, lock contention, or a slower downstream; diff dependencies and config, a bumped client library or changed pool size is a classic; check pool saturation, since a slightly slower dependency converts directly into queueing; then trace one slow request end to end, which usually ends the investigation. Mitigations: roll back if the diff is suspect, restore pool sizes, pin the previous library. The lesson to state: latency regressions live in the waits, so measure the waits, and tracing beats speculation. This regression class hides in waits rather than CPU, which is why system design interview questions hand you the deploy timeline as the first clue.

Answer: The checks and the users measure different things, so align them. Diagnose: compare what health checks exercise, usually a static liveness endpoint, against the failing path, usually a dependency call; reproduce the user’s failure and watch which dependency errors. Common culprits: the check passes while the connection pool is exhausted, while a downstream times out, or while the instance serves from stale config. Fix in layers: make readiness reflect the true serving condition, dependencies included but cheaply, so the balancer stops routing to actually-broken instances, and make the failure graceful, degrade the feature instead of returning 500. The point: health is defined by the user’s path, not by process existence.

Answer: Confirm the diagnosis first: waits on pool acquire in metrics or logs, threads parked on getConnection, while the database itself is healthy. Then find who holds the connections: slow queries past the pool timeout, transactions held open across external calls, a dependency outage making every request hold its connection while waiting, or a pool sized for less traffic than arrived. Fixes in order: bound request concurrency to pool size so excess queues at the edge instead of inside; move external calls out of transaction scope; size the pool with Little’s law against the database’s real capacity. State the mechanism: exhaustion turns one slow dependency into whole-service failure, which is why every external call needs a timeout. Pool exhaustion is where system design interview questions test whether you size from math or from vibes.

Answer: Periodicity is the clue, so correlate first: what else runs at that hour, backups, rollups, compaction jobs, and compare against per-hour metrics for the pipeline and the machines it shares. Confirm overlap with resource evidence: disk saturation, CPU steal, or database contention from a batch job competing for the same tables. Fixes follow the finding: reschedule the collision, isolate the batch onto separate capacity, or rate-limit the batch so interactive work keeps latency headroom; if the pipeline is the scheduled job, smooth its parallelism. Then automate the check: alert when the daily job and the pipeline’s p95 overlap. Same-time-every-day slowness is a schedule problem until proven otherwise, and that sentence is the answer.

Answer: Wrong destinations mean the mapping layer diverged, so establish which layer lies: sample codes and compare old store, new store, and cache; the mismatch location names the bug. Likely causes: a base62 encoding or case-handling mismatch, partial backfill leaving some codes resolving to stale rows, or caches populated during cutover holding pre-migration values. Contain by purging the affected cache range and routing reads to the verified store, then re-verify with checksums across the full keyspace before re-enabling cache fills. Prevent with a runbook rule: migrations verify by checksum, never by row count. The graded skill is isolating which layer of the read path disagrees with the source of truth. It is also the reason system design interview questions about migrations grade verification discipline more than cutover speed.

Answer: New users have empty precomputed feeds, so every read falls back to merge-on-read across hundreds of follows at once: a cold-start fan-out, not a general slowdown. Confirm by correlating account age with latency, then fix the cold start: on signup, synchronously precompute a seed feed from the most recent posts of a bounded follow set, with background jobs filling the rest; cap the merge window, newest N posts per source, so a read can never fan out to unbounded history. Protect the read path with a per-request fan-out budget that returns partial results instead of timing out. The general lesson worth saying aloud: cold-start paths bypass every warm-path optimization, so design and load test them separately.

Answer: Bursts slip through when limiter state dies with the node or loses consistency in failover, so diagnose where counters lived: in-process on the failed node, or in a shared store that failed over with relaxed consistency. Immediate fixes: fail the counter store over with the limiter or reconstruct limits on takeover from recent request logs; shrink downstream pool sizes so residual bursts cannot overwhelm the backend; add a defensive secondary limiter at the service layer. Durable design: sticky routing so users and their counters travel together, and accept-the-count semantics where losing a fraction of counter updates beats losing the limiter. The principle: the limiter is critical-path infrastructure and deserves real failover design, not best effort. It is the textbook example of a stateless-looking component hiding critical state, a trap system design interview questions return to often.

Answer: Two readers seeing different states means the reads hit different replicas, so prove it: log which replica or region each reader’s query used, compare against the write’s replication position, and the divergence will map to lag or a partitioned write path. Immediate: route a customer’s order reads to the replica their writes landed on, or the primary, using read-your-own-writes tokens. Then decide the product answer deliberately: order status tolerates seconds of staleness behind a visible “updating” state, while payment states do not, so those reads pin to a consistent quorum. Publish a staleness budget per state and alert when replication approaches it. Consistency complaints in system design interview questions test whether you can name which reads must be fresh, and why.

Answer: Audit in attribution order: per-service, per-bucket, per-table growth over twelve months first, because one team’s retention bug usually owns most of the curve. Classify what you find: data held past retention policy, replicas and snapshots multiplied beyond need, uncompressed formats where columnar compression applies, and orphaned artifacts from dead experiments. Fixes by leverage: lifecycle rules first, expire, transition cold, delete incomplete uploads, which often recovers half alone; convert analytics data to columnar formats with compaction; right-size replication to the durability requirement rather than to fear. Institutionalize: per-team cost attribution with budgets and growth alerts before quarter-end. Cost problems are ownership problems first, and naming that is the graded insight.

Answer: Dual-write, backfill, verify, cutover, cleanup. Start dual-writing to the new layout while the old one serves all reads; backfill history in background batches with rate limits so production latency holds; verify by checksums and sampled comparisons, never counts alone. Cut reads over incrementally, 1 percent, 10, 50, watching error and latency budgets, with an instant flip-back path at every step; writes stay dual until the old layout has been read-free for a full traffic cycle, weekly patterns included. Then stop dual-writes and retire the old shards. Address the two traps by name: hot shards in the new key space, checked before cutover, and in-flight transactions spanning the switch. Verification steps are what make this answer senior.

Answer: Establish which model you actually have: writes to different regions for the same key means divergent histories, and the reconciliation rule decides outcomes, so make it explicit before merging. The options: last-write-wins by timestamp silently drops writes under clock skew; application-level merge is correct but must be written per data type; CRDTs merge mathematically for counters, sets, and registers. Immediate steps: stop one region’s writes to prevent new divergence, export both sides’ conflict logs, replay through the chosen resolver, and audit the results. Prevent: single-writer semantics, each record homed to one region, with conflicts monitored as an SLO breach. Active-active is a product decision about acceptable conflicts, made before the first one, not after. Conflict reconciliation is where system design interview questions cross from architecture into data governance.

Answer: Quantify the deficit first: events in versus notifications delivered, per hour, and where the pipeline backs up, queue depth, consumer throughput, or provider rate limits, because the fixes differ. Usual live-event culprits: a thundering herd of reads preceding the fan-out, per-recipient provider throttling, or amplification, one event times millions of followers. Relief now: batch aggressively, group per recipient, prioritize classes, drop or defer low-value ones, and raise consumer parallelism to the provider’s ceiling. Structural: precompute recipient lists for known-large sources, shard the fan-out by recipient so it parallelizes, and replace silent lag with backpressure plus a declared staleness SLO. Notification systems are queueing systems, so capacity math plus priority tiers is the whole answer.

Answer: Trace the pipeline stage by stage: write accepted, queue depth, indexer consumption rate, refresh interval, replica propagation, because lag accumulates wherever production exceeds consumption. Usual causes: indexers under-provisioned relative to write volume, oversized segments from sparse refreshes, or a refresh interval tuned for throughput instead of freshness. Fixes: scale indexers horizontally with partitioned queues, shorten refresh intervals for the fields users search immediately while keeping the rest lazy, and dedicate partitions to this index so batch reindexes cannot starve it. Set the SLO honestly, search-is-eventual is a product decision, publish it, and alert at 80 percent of budget. Search lag is a queueing problem with a freshness SLO, and framing it that way is most of the fix.

Answer: The test modeled the wrong things, so enumerate what, in likelihood order: traffic shape, smooth synthetic load versus a real spike with a login storm at open; data skew, uniform fixtures while production has hot keys and celebrities; state, cold caches and empty pools at start, since tests always run warm; and dependencies, third parties and auth at production rates, or not simulated at all. Also check what the test measured: averages hide the tail that pages people. Fix the harness before the architecture: replay production traffic shapes, include cold-start runs, test dependency failure modes, and gate the launch on the replay, not the synthetic. Skepticism about your own load test is exactly what launch-day system design interview questions exist to find.

Answer: Build the map before touching anything: inventory services and data stores, then instrument, latency percentiles and error rates per endpoint, dependency maps from traces, and the deploy timeline, because regressions correlate with changes before they correlate with anything else. Hunt the cheapest wins first: missing indexes in slow queries, unbounded caches, pool misconfigurations, and N+1 query patterns, the usual suspects when p99 climbs without a traffic change. Make one improvement, measure it, and write down what you learned; the documentation you wish existed is the one you write as you go. Close by proposing capacity or architectural work with evidence, and the team inherits a model instead of a mystery. Method over heroics, evidence over instinct. That same posture is what system design interview questions reward when the prompt hands you an unfamiliar system.