CHAPTER 13
Design a URL Shortener
A deceptively simple read-heavy system: unique keys, redirects, caching, analytics
Source: PDF p. 49
Each case study in this part follows the same template: requirements, estimation, API and data model, high-level design, deep dives, and trade-offs. Use it as your interview skeleton.
| Functional requirements | Non-functional requirements and scale |
|---|---|
| - Create a short URL for a long URL (optional custom alias, expiry) - Redirect short URL to the original - Basic click analytics - Delete / expire links | - Very high availability for redirects (99.99%), p99 < 100 ms - Short links must not be guessable or collide - 500 M new links/month, read:write = 100:1 - Links stored for 5+ years |
| Quantity | Estimate | Design implication |
|---|---|---|
| Write QPS | 500 M / (30 x 86,400) = ~200/s (peak ~600) | Trivial for one DB; scale is in reads |
| Read QPS | 200 x 100 = 20,000/s (peak ~60,000) | Cache hot links; replicas; CDN optional |
| Total records (5 years) | 500 M x 12 x 5 = 30 B | Needs sharding or a scalable KV store |
| Storage | 30 B x ~500 B = ~15 TB | Fits a modest sharded cluster |
| Code length | 62^7 = 3.5 T > 30 B | 7 base-62 characters are enough |
API and data model p. 49
POST /v1/urls
{"long_url": "...", "custom_alias": "?", "expires_at": "?"}
-> 201 {"short_url": "https://sho.rt/aZ3kP9q"}
GET /{code} -> 302 Location: <long_url>DELETE /v1/urls/{code} -> 204
Table urls(code PK, long_url, user_id, created_at, expires_at). Access is purely by key, so a key-value / wide-column store (DynamoDB, Cassandra) or a sharded SQL table keyed by hash(code) fits. Click events go to a stream (Kafka), never to the redirect path.
Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.
Try it
References
System Design & AI System Design: The Complete Guide — 2026 Edition, p. 49; figures 34.
Tip: use ← and → keys to move between chapters.