180: System Design - Complete Case Study
Practice
Design a URL shortener, notification service, or collaborative task system from requirements to APIs, data model, components, scaling limits, security boundaries, and failure modes. Include one diagram and one sequence trace.
Review
Challenge every component: what problem does it solve, what does it cost, and what happens when it is unavailable? Record two simpler alternatives and why they were rejected.
Checkpoint
Deliver a ten-minute explanation that distinguishes current design from future scaling work.
Review rubric
Start with requirements, then draw the simplest architecture that satisfies them. State the data owner, consistency promise, hot path, cold path, capacity assumption, security boundary, and failure recovery. Add a component only when a named requirement or measured bottleneck justifies it.
Worked case: URL shortener
Assume authenticated creation, public redirects, 1 million new links/month, 100:1 redirect-to-create ratio, and a custom alias with conflict errors. POST /links validates the destination, reserves a unique short code in a relational store, and returns it. GET /{code} checks a cache, then the database, records an asynchronous click event, and redirects. The database is authoritative; cache misses and event loss must not prevent a redirect.
Use a unique constraint for code races, a bounded alias length, safe URL schemes, and authorization on management endpoints. Hash-based codes simplify generation but require collision handling; random codes need sufficient entropy and retry limits. Do not put untrusted destinations into an HTML page without escaping. At higher scale, partition by code, add read replicas or a distributed cache, and batch analytics, but name the measured bottleneck first.
Required submission and rubric
Submit assumptions, APIs, schema/indexes, architecture diagram, create/redirect sequence, one failure sequence, capacity math, security boundary, and two rejected alternatives. Score 3 points each for requirements, consistency/data ownership, scale estimates, reliability, security, and communication. Full credit distinguishes synchronous redirect correctness from eventually consistent analytics.