Problem statement
Design a URL shortener service (think bit.ly / tinyurl) that maps arbitrary long URLs to compact short codes and serves redirects globally.
Operating context. You are designing the v1 of a public, free product. Anonymous users can shorten URLs; authenticated users additionally see lifetime analytics for the codes they own. Traffic is heavily read-skewed: roughly 100 writes/sec sustained, with read traffic 100× to 1000× that on a typical day and bursty spikes on viral links. Latency budget for the redirect path is p99 < 100 ms globally.
Out of scope. Custom domains, paid tiers, fine-grained ACLs, link expiry/UTM injection, abuse-detection ML. Assume a separate team owns those.
What to produce. A high-level architecture covering: the request paths (shorten + resolve), the data model and partitioning choice, how short codes are generated without collisions, the caching strategy, the geographic distribution story, and where analytics are recorded without slowing the hot redirect path. Sketch the major components and the request flow between them; we will probe specifics during checkpoints.
Functional requirements
- Shorten a long URL into a 6–8 character short code, returning a fully qualified short URL.
- Resolve a short code to its original URL via HTTP 301 (or 302 for codes with analytics).
- Allow authenticated users to list the codes they own with basic per-code hit counts.
- Surface a friendly 404 page for unknown / disabled codes.
Non-functional requirements
- Read path p99 < 100 ms globally; write path p99 < 300 ms.
- Sustain 100 writes/sec with bursts to 1000 writes/sec for short periods.
- Serve 10000 reads/sec at steady state, 100000 reads/sec at viral peak.
- 99.95% availability for the resolve path; 99.9% for the shorten path.
- Durable storage of the long-URL mapping — no data loss on single-AZ failure.
- Short codes are non-guessable to a casual scraper but need not be cryptographically secret.
Topics
- System Design HLD
- Data KV
- Data Cache
- Infra CDN
- Scaling Read-Heavy