System Design interview questions

What a strong answer covers

• Clarify functional requirements (shorten a URL, redirect, optional custom alias, expiry, analytics) and non-functional ones (high availability, low-latency redirects, read-heavy).
• Do rough estimates: assume writes/day and a read:write ratio (often 100:1), derive QPS, storage per record, and total storage over a few years to size the system.
• Core design: a key-generation strategy (base62 of an auto-increment ID or a hash) mapping short code to long URL, stored in a key-value or relational store, fronted by a cache for hot links.
• Redirect returns a 301/302; note the trade-off (301 is cacheable and cheaper but breaks click analytics, 302 keeps every hit hitting your service).

Where people lose the point

• ×Jumping straight into a schema or database choice before pinning down requirements and read/write ratio.
• ×Ignoring the estimation step, so the design has no justification for its scale decisions.
• ×Proposing a random hash without addressing collision handling or short-code length.

What a strong answer covers

• Vertical scaling adds resources (CPU, RAM) to one machine: simple, but has a ceiling, a single point of failure, and costs rise nonlinearly.
• Horizontal scaling adds more machines behind a load balancer: near-linear headroom and fault tolerance, at the cost of coordination, statelessness, and data-distribution complexity.
• A load balancer spreads traffic across instances (round-robin, least-connections, or hashing) and does health checks so dead nodes are removed from rotation.
• Stateless app servers make horizontal scaling clean; session/state must move to a shared store (Redis, DB) or use sticky sessions with their downsides.

Where people lose the point

• ×Claiming horizontal scaling is strictly better without acknowledging the added complexity and data-consistency cost.
• ×Forgetting that horizontal scaling requires stateless servers or externalized session state.
• ×Not mentioning health checks, so the load balancer keeps routing to a dead node.

What a strong answer covers

• Identify cache layers: client/browser, CDN for static and edge content, an application cache (Redis/Memcached) for hot query results, and DB-level caching.
• Pick a pattern: cache-aside (lazy load on miss) is the common default; write-through keeps cache fresh at write cost; write-back trades durability for write speed.
• Set expiry/eviction policy (TTL plus LRU/LFU) sized to memory, and reason about the working set that actually needs to be hot.
• Address invalidation and consistency: stale reads after writes, and stampede protection (locking, request coalescing, or staggered TTLs) when a hot key expires.

Where people lose the point

• ×Treating cache invalidation as an afterthought and serving stale data with no strategy.
• ×Ignoring the thundering-herd / cache-stampede problem when a popular key expires under load.
• ×Caching everything indiscriminately instead of targeting the hot working set, wasting memory and hurting hit rate.

What a strong answer covers

• First exhaust cheaper options: read replicas for read scaling, indexing, and vertical scaling; shard only when a single node's write throughput or storage is the true limit.
• Choose a shard key and strategy: hash-based (even distribution but hard range queries), range-based (good for ranges but risks hotspots), or directory/lookup-based for flexibility.
• Consistent hashing minimizes data reshuffling when nodes are added or removed, versus naive modulo which remaps almost everything.
• Name the costs: cross-shard joins and transactions get hard, hotspots form on skewed keys, and rebalancing is operationally painful, so pick the shard key around your dominant access pattern.

Where people lose the point

• ×Reaching for sharding before trying replicas, indexing, or caching, which solve many read-scaling problems more cheaply.
• ×Choosing a shard key that creates hotspots (e.g. sharding by timestamp for write-recent workloads).
• ×Hand-waving over cross-shard queries and transactions, which are the main thing sharding sacrifices.

What a strong answer covers

• CAP: under a network partition a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response); with no partition you can have both.
• Map real systems: an AP store (Dynamo/Cassandra) stays writable during partitions and reconciles later; a CP store (traditional RDBMS, ZooKeeper) refuses or blocks to avoid divergence.
• Apply it: a shopping cart favors availability and merges conflicting writes (last-write-wins or CRDT-style union) since a temporarily wrong cart is acceptable; a bank ledger or inventory decrement favors consistency to avoid double-spend.
• Go beyond CAP to eventual vs strong consistency and PACELC (even without partitions there is a latency-vs-consistency trade-off), and mention quorum reads/writes (R + W > N) as a tunable middle ground.

Where people lose the point

• ×Stating you can simply 'have all three' or that CAP forces a permanent choice rather than one that applies during partitions.
• ×Picking strong consistency everywhere by reflex without weighing the availability and latency cost for the use case.
• ×Confusing consistency in CAP (linearizability of reads) with ACID consistency (constraint validity), which are different notions.

What a strong answer covers

• Clarify scale and requirements: number of users, average vs celebrity fan-out, freshness expectations, ranked vs chronological, and the heavy read:write skew of feed reads.
• Contrast fan-out-on-write (precompute each follower's feed on post, fast reads, expensive for high-follower accounts) with fan-out-on-read (assemble at query time, cheap writes, slower reads).
• Adopt a hybrid: fan-out-on-write for normal users, but pull celebrities' posts at read time to avoid write amplification, then merge and rank.
• Cover storage and delivery: a per-user feed cache in Redis, a ranking layer, pagination via cursors, and pushing updates via polling or websockets, plus how to backfill/rebuild a cold feed.

Where people lose the point

• ×Choosing pure fan-out-on-write without handling the celebrity / high-fan-out write-amplification problem.
• ×Never estimating the read:write ratio, so the design optimizes the wrong path.
• ×Ignoring feed ranking, pagination, and cache-warming, and treating the timeline as a simple ORDER BY over all posts.