URL shortener at scale
The interview classic, production-grade: k-sorted Snowflake IDs, hash-sharded storage, cache-aside reads with negative caching, and 302s served from the CDN edge.
What this design does
Everyone designs this in interviews; here is what actually holds at billions of redirects. Slugs come from Snowflake-style IDs (time-ordered, no coordination, no collisions to check). Storage shards by hash of slug so no shard is hotter than another. Reads are cache-aside with the trick most designs miss — negative caching, so a bot spraying random slugs hammers the cache's 404s instead of your database. And the redirect itself is cached at the CDN edge, where most lookups never reach you at all.
The patterns it composes
- Snowflake-style ID generation — time | worker | sequence — unique without coordination
- Hash sharding — hash(slug) picks the shard; load spreads evenly by construction
- Cache-aside — reads hit the cache first; misses fill it from the right shard
- Negative caching — unknown slugs cache their 404 — random-slug bots can't reach the DB
- CDN edge caching — popular redirects are answered before touching the origin
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.