System Design Fundamentals Quiz

CAP says that when a network partition occurs, a system must choose between staying consistent (rejecting requests it cannot safely serve) or staying available (serving possibly stale data). Partition tolerance is not optional in a distributed system — partitions will happen — so the real trade-off is C versus A during the partition.

With modulo hashing, changing N remaps almost every key, causing a cache-miss storm that can crush the database behind the cache. Consistent hashing places nodes on a ring, so adding or removing a node only moves the keys in that node's segment — roughly 1/N of them. It has nothing to do with consistency guarantees; the name refers to keys staying consistently placed as membership changes.

In cache-aside, the cache is passive: the application checks the cache, and on a miss it queries the database itself and populates the cache before returning. This is different from read-through caching, where the cache layer owns the database fetch. Cache-aside is the most common pattern because it keeps the cache simple and tolerates cache failures gracefully.

Sharding by user_id keeps each user's posts on one shard, so per-user reads, writes, and deletes stay single-shard and fast. A global query like 'latest posts across all users' must fan out to every shard and merge the results (scatter-gather), which is exactly the access pattern the shard key does not serve. Choosing a shard key is choosing which queries stay cheap.

A Layer 4 balancer only sees IPs and ports, so it can spread TCP/UDP connections but cannot inspect what is inside them. A Layer 7 balancer parses HTTP, so it can route /api/video to the video service, do path-based canary routing, or make decisions on cookies and headers. Both can health-check and distribute load — content-aware routing is the L7-only capability.

With asynchronous replication, replicas apply writes slightly after the primary, so a read-after-write sent to a replica can return stale data. The standard fix is read-your-own-writes consistency: route a user's reads to the primary for a short window after they write, or use session tokens/LSN tracking. This is one of the most commonly probed follow-ups in system design interviews.

Networks fail after a request is processed but before the response arrives, so clients must retry — and without idempotency, a retry double-charges the customer. The idempotency key lets the server recognize a repeat of an operation it already executed and return the stored result instead of executing again. Any mutation that can be retried needs this property.

A queue turns a synchronous dependency into an asynchronous one: the web service enqueues the job in milliseconds and responds, while workers drain the queue at their own pace. Bursts pile up in the queue instead of timing out user requests. Queues do not make work faster and most give at-least-once delivery, so consumers still need to be idempotent.

CDNs shine when many users request the same bytes, because edge servers can cache one copy and serve everyone nearby. A personalized, per-user API response has a cache hit ratio near zero — every user's copy is different — so the CDN adds little beyond TLS termination close to the user. Static, shared assets are the canonical CDN workload.

A token bucket accumulates tokens at a fixed refill rate up to a maximum capacity; a burst can spend all accumulated tokens at once, but the long-term average is capped by the refill rate. Fixed windows allow edge-of-window double bursts, and a strict leaky bucket smooths output to a constant rate with no bursting. Token bucket's burst-friendliness is why it is the default answer in rate limiter designs.

There are 86,400 seconds in a day, so 86.4 million requests / 86,400 seconds = 1,000 requests per second. This 'divide by ~10^5' shortcut (a day is about 10^5 seconds) is the single most useful back-of-envelope trick in system design interviews — and remember peak traffic is typically 2-5x the average.

If session state lives in the app server, requests must 'stick' to that server, and losing it logs users out. Moving state to a shared store (Redis, a database, or a signed cookie/JWT) makes every app server interchangeable: the load balancer can send any request anywhere, autoscaling just adds identical instances, and a crashed server loses nothing. State has to live somewhere — the point is to keep it out of the compute tier.

The quorum condition is R + W > N: any read set must overlap any write set in at least one replica. With N=3 and W=2, R=2 gives 2+2=4 > 3, so every read touches at least one replica that has the newest write. R=1 could hit the single replica the write skipped. This overlap argument is the standard way interviewers probe whether you understand tunable consistency in systems like Dynamo or Cassandra.

Fan-out on write does work proportional to the author's follower count: one celebrity post triggers 100 million feed insertions, which can take minutes and flood the write path. That is why real feed systems use a hybrid — push for normal users, pull (fan-out on read) for high-follower accounts, merging at read time. Frequent readers are the case push handles best, not worst.

Polling wastes resources (most polls return nothing) and adds latency up to the polling interval. A WebSocket keeps one TCP connection open, so the server pushes a message the moment it arrives — no request/response handshake per message and no wasted empty polls. WebSockets do not provide offline delivery or extra encryption (that is TLS); those need queues and persistence on top.

Object storage is built for exactly this: effectively unlimited capacity, high durability via internal replication, cheap per-GB pricing, and direct HTTP access that CDNs can pull from. Databases handle large binaries poorly (bloated storage, slow backups, wasted cache), local disk ties files to one server's lifetime, and RAM-based Redis is orders of magnitude too expensive. 'Files in object storage, metadata in the database' is the default pattern to state in interviews.

Vertical scaling is simple (no code changes) but hits a wall: the biggest available machine, at a steep price curve, and it is still one failure domain — when it dies, everything dies. Horizontal scaling adds commodity machines indefinitely and tolerates individual failures, at the cost of the distributed-systems problems (state, coordination, consistency) that system design interviews are about. Adding machines improves throughput, not per-request speed.

OFFSET 100000 forces the database to walk 100,000 rows just to throw them away, so deep pages get slower and slower. And because new inserts shift every subsequent row, a user paging through a live feed sees duplicates or misses items. A cursor ('everything after item_123, ordered by an indexed key') is a direct index seek — constant cost at any depth and stable under concurrent writes. This is why feed APIs are cursor-based.

Without a TTL, a client that acquires the lock and then crashes (or loses network) never releases it, and the protected resource is deadlocked permanently. The TTL turns the lock into a lease: it self-releases after a bounded time. The trade-off is that a slow-but-alive client can outlive its lease and two holders can briefly overlap — which is why lock values carry a unique owner token checked on release, and why truly critical sections also need fencing tokens downstream.

A load balancer spreads traffic across copies of one service; an API gateway is the single front door to many services, where cross-cutting concerns live once instead of being reimplemented in every microservice: token validation, per-client rate limits, routing /orders vs /users to different backends, request/response transformation, and sometimes aggregating several internal calls into one client response. Both can terminate TLS and balance load — the API-level responsibilities are the differentiator.