System Design interview questions & practice path
Scaling, caching, load balancing, and data-partitioning trade-offs. Learn what interviewers probe, drill the questions until answers come fast, then prove it in a scored mock, all in one System Design path inside Round Zero.
- Concept lessons that explain the why, not just the answer
- Practice questions with adaptive follow-ups and flashcards
- A scored mock with evidence quoted from your own answers
Sample System Design questions
What a strong answer covers, and the mistakes interviewers watch for. The scored path drills every one with live follow-ups.
You are asked to 'design a URL shortener like TinyURL.' How do you start?
easyA 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).
Common mistakes
- 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.
Explain horizontal vs vertical scaling, and how a load balancer fits in.
easyA 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.
Common mistakes
- 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.
Where and how would you add caching to a read-heavy service, and what are the pitfalls?
mediumA 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.
Common mistakes
- 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.
Your primary database can no longer hold or serve the data on one node. Walk me through sharding, and what breaks.
mediumA 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.
Common mistakes
- 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.
Explain the CAP theorem, and how it drives a design decision like a distributed shopping cart or bank ledger.
hardA 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.
Common mistakes
- 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.
Design the news feed for a social network. How do you generate and serve each user's timeline at scale?
hardA 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.
Common mistakes
- 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.
How System Design answers are scored
Requirements and scoping
30%Clarifies functional and non-functional requirements before designing, identifies the real bottleneck, and does back-of-the-envelope estimates (QPS, storage, bandwidth) that steer the design instead of guessing.
Architecture and trade-offs
45%Proposes a coherent end-to-end design and justifies each component choice against alternatives, explicitly naming the trade-off (consistency vs availability, latency vs cost, read vs write optimization) rather than dropping in buzzwords.
Communication and iteration
25%Drives the conversation top-down, starts with a high-level diagram before deep-diving, states assumptions, and adapts the design gracefully when the interviewer adds constraints or failure scenarios.
Role tracks that include System Design
Software Engineer interview prep
Core coding, data, and systems skills most SWE loops probe before the onsite.
System Design interview prep
Architecture, distributed systems, and depth for senior/staff design rounds.
Backend Engineer interview prep
Coding fundamentals, databases, API and service design, and system design across a typical backend loop.
Mobile Engineer interview prep
Platform language depth, cross-platform frameworks, and coding rounds that mobile app loops test.
Machine Learning Engineer interview prep
ML fundamentals, model building, coding, and production deployment that ML engineering loops probe from screen to onsite.
Engineering Manager interview prep
People leadership, conflict handling, and technical judgment an EM loop probes through behavioral and system design rounds.
Related CS Fundamentals skills
All skills →No spam. Unsubscribe anytime.
Ready to master System Design?
Sign up free. Your System Design path includes lessons, drills, flashcards, and a scored mock with feedback on what to fix.
- ✓ Concept lessons plus practice questions
- ✓ Flashcards for spaced repetition
- ✓ A scored mock with evidence quotes
Questions & answers
- What System Design interview questions should I practice?
- Start with the core areas System Design interviewers probe: You are asked to 'design a URL shortener like TinyURL.' How do you start; Explain horizontal vs vertical scaling, and how a load balancer fits in.; Where and how would you add caching to a read-heavy service, and what are the pitfalls. This page outlines strong answers and common mistakes, and the scored path drills each one with follow-ups.
- Is the System Design practice free?
- Yes, you can start a System Design path free inside Round Zero. It generates lessons, practice questions, flashcards, and a scored mock. Sign up to unlock the full drills and your evidence-backed scorecard.
- How is this different from a System Design question list?
- A static list gives you questions with no feedback. Round Zero runs a live scored practice that probes your actual answers, rotates difficulty, and tells you exactly what to fix, grounded in a System Design rubric.
- How should I prepare for a System Design interview?
- Learn the concepts, drill the questions until answers come fast, then prove it in a scored mock. Round Zero sequences all three so you know you are ready, not just that you read about System Design.
- How is a System Design answer scored?
- System Design answers are scored on requirements and scoping, architecture and trade-offs, communication and iteration, with evidence quoted from what you actually said, so feedback is specific instead of generic praise.