URL Shortener
Architecture decision record
Fictional person and company · Pre-generated example · No live AI callArchitecture
5 componentsQuestion and example context
Alex Chen · Mid Backend EngineerHarbour Link (fictional)
Design a URL shortening service. Explain the source of truth, redirect path, collision handling and degraded behaviour.
Decisions and review
6 sections01Requirements and assumptions
This fictional workload creates 100 million links per month, with 100 redirects per created link. Assuming a 30-day month, this is approximately 38.6 writes/s and 3,858 reads/s on average. These assumptions match the existing Lab topic; they are not measured peak capacity. Peak traffic, retention, regional availability and abuse policy remain open requirements.
02Architecture and state ownership
A creation API validates the destination, allocates a code and commits the code-to-URL mapping to durable storage before acknowledging success. A redirect service checks the cache, reads the mapping store on a miss and then populates the cache. The mapping store is authoritative; the cache is a disposable copy. The diagram separates creation and redirect paths, even if a small initial deployment shares compute.
03Collision and security decisions
A unique constraint detects duplicate codes; allocation retries after a conflict. Creation is rate limited and destinations are checked against an abuse policy. Random codes are not an access control mechanism. Private links would require an explicit authorization design.
04Failure and recovery
When the cache fails, redirects may fall back to the store within a bounded concurrency budget; excess traffic receives a clear retryable failure. When both the cache misses and the authoritative store is unavailable, the service fails rather than inventing a destination. Recovery should warm popular keys gradually and monitor store saturation.
05Trade-off and limits
The initial proposal uses a durable mapping store plus cache because reads dominate this assumed workload. This does not establish that one database meets production requirements. Sharding or regional replicas require evidence about peak load, storage growth, latency and consistency. No production load or recovery experiment was executed for this example.
06Feedback and next action
The answer identifies the state owner and explains cache failure without treating cache as the only copy. It still needs a justified origin concurrency limit, peak-load assumptions, expiration semantics and a recovery experiment. Use the existing Lab to inspect the available topology and failure paths, then explain what changes under a new constraint. This feedback is pre-generated, not an employer assessment or a live AI result.
Explore data paths, architecture choices and failure behaviour in the interactive Lab.
Keep preparing
Mock interviewMy preparation workspace
Continue existing targets, rounds, tasks and evidence in one workspace.
Questions and review
Practice questions, keep answers and feedback, and return to the current round.
System Design
Reference reading and interactive simulations share topic resources and preserve existing Lab progress.
Interactive Lab
Explore data paths, architecture choices and failure behaviour in the interactive Lab.