- Experience building or operating software systems
- Working knowledge of APIs, databases, caching, queues, networking, and basic scalability concepts
Career Skills · Software Professionals
System Design Interview
A structured path for designing scalable systems and explaining tradeoffs clearly in technical interviews.
Course roadmap
Know where you are going before you begin
A useful course should make the starting point, destination, and learning method clear—not make you guess from a list of links.
Learning material
Inside this course
Move through the material in order unless a prerequisite or practice link gives you a better reason to branch.
1. GuideA Repeatable System Design Framework
20 min A step-by-step structure for approaching design interviews.
2. InterviewDesign a URL Shortener
28 min Walk through requirements, data model, APIs, scaling, and failure modes.
3. NotesCore System Design Concepts
14 min Fast reference for caching, queues, partitioning, consistency, and observability.
Learning connections
Continue with purpose
These are curated relationships from the SubjectVision learning graph. Each recommendation should answer why it is useful next rather than merely adding another link.
Interview preparation
Course interview practice
Use these as compact whiteboard drills after the course. Clarify the requirement first, estimate only what changes the design, sketch the critical request and data paths, then explain bottlenecks, failure behavior, and the trade-off you chose.
01 · IntermediateYou are asked to design a messaging service. What should you clarify before choosing databases, queues, or caches?Answer out loud before opening the expected response.
Practice
Answer out loud before opening the expected response.
Expected answer
Clarify the users and core actions, one-to-one versus group messaging, delivery expectations, ordering, retention, attachment needs, online/offline behavior, expected scale, latency goals, and which failures the product must tolerate.
Why this answer works
A system design interview is not a guessing contest about the interviewer’s preferred stack. Requirements determine the architecture. The strongest opening turns vague product language into constraints that can influence data modeling, consistency, fan-out, storage, transport, and recovery choices before technologies enter the discussion.
02 · SeniorFor a URL shortener, how would you reason about generating short identifiers without creating a central bottleneck?Answer out loud before opening the expected response.
Practice
Answer out loud before opening the expected response.
Expected answer
First define the collision and predictability requirements, then compare approaches such as database-generated ranges, distributed ID generation, or sufficiently large random identifiers with collision detection. Choose based on throughput, coordination cost, and operational simplicity.
Why this answer works
There is no universally correct ID algorithm. A single incrementing database sequence is simple but can concentrate coordination; random IDs distribute generation but require a collision strategy; preallocated ranges reduce coordination but add operational bookkeeping. State which property matters most, then justify the smallest design that satisfies it.
03 · SeniorA read-heavy service becomes fast after adding a cache, but users sometimes see stale data after updates. How would you reason about the fix?Answer out loud before opening the expected response.
Practice
Answer out loud before opening the expected response.
Expected answer
Start by defining how stale the product is allowed to be and which writes require immediate visibility. Then choose an invalidation, update, TTL, or versioning strategy that meets that consistency requirement instead of treating cache eviction as an isolated performance tweak.
Why this answer works
Caching introduces a second copy of data, so it creates a consistency problem as well as solving a latency problem. A good answer names the source of truth, explains when cached entries become invalid, considers races and cache misses, and accepts bounded staleness only when the product requirement allows it.
04 · SeniorA partitioned datastore is evenly sized overall, yet one partition receives most of the traffic. What should you investigate and change?Answer out loud before opening the expected response.
Practice
Answer out loud before opening the expected response.
Expected answer
Inspect the partition key and access distribution for hot tenants, timestamps, sequential IDs, celebrity-style records, or other skew. A fix may require a better key, bucketing or salting, request spreading, caching, or isolating unusually hot workloads.
Why this answer works
Partition count alone does not guarantee scalability. The partition function must distribute the actual workload, not just the stored bytes. Strong answers separate storage balance from request balance and explain the new costs introduced by techniques such as salting, including scatter-gather reads or more complex aggregation.
05 · ArchitectA queue can occasionally deliver the same job more than once. How should the consumer be designed so retries do not corrupt business state?Answer out loud before opening the expected response.
Practice
Answer out loud before opening the expected response.
Expected answer
Assume duplicate delivery is possible and make the business operation idempotent, for example by using a stable operation key, conditional write, deduplication record, or state transition that can safely recognize an already-applied action.
Why this answer works
Retries improve reliability only when repeated execution is safe. “Exactly once” is often an end-to-end business property rather than a magic broker setting. A strong answer identifies the side effect being protected, defines the idempotency boundary, explains how concurrent duplicates are handled, and considers retention or cleanup of deduplication state.
Knowledge check
Test what you can apply
Five course-specific questions covering the most important ideas in System Design Interview. Commit to an answer before reading the explanation.
Score0 / 50 answered
01
An interviewer says, “Design a photo-sharing service.” What is the strongest first move?
The prompt is intentionally ambiguous. Clarifying functional and non-functional requirements creates the constraints that make later design choices defensible. Choosing technologies first risks solving the wrong problem; premature service decomposition and unlimited assumptions add complexity without evidence.
Review this topic →02
A read endpoint is expected to receive 20,000 requests per second, while writes are about 100 per second. Why is that estimate useful before drawing the architecture?
Scale estimates reveal the workload shape and help identify likely bottlenecks. They inform whether caching or replicas may help, but they do not make one solution automatically correct. They also do not choose a language or replace reliability analysis.
Review this topic →03
A product team adds a cache to reduce database load. A user updates her profile but immediately sees the old value. Which design concern has appeared?
The cache improved latency/load but introduced a stale-data problem, so the design now needs an invalidation, expiry, or consistency strategy. The database can still persist data; a queue is not inherently required; and API synchronicity does not by itself solve stale cached values.
Review this topic →04
A URL shortener receives a request for /aB91x. On the critical redirect path, what must the system do efficiently?
The essential read-path job is short-code lookup followed by a redirect. Code generation belongs to the write path, analytics can usually be decoupled from the latency-sensitive redirect, and link creators should not be part of serving a stored redirect.
Review this topic →05
Two candidate designs both meet the functional requirements. Design A is simpler but can lose a few minutes of analytics during a regional outage; Design B avoids that loss but doubles operational complexity and cost. What makes a strong interview answer?
A strong system-design answer ties the decision to explicit requirements and explains the trade-off. Neither maximum durability nor minimum component count is universally correct, and adding technologies without a requirement is complexity rather than architectural reasoning.
Review this topic →Complete
Review any missed answers, then continue while the concepts are fresh enough to connect.