sydepsystem design atlas

URL Shortener

Create short aliases, then redirect quickly from a cache-backed read path.

IntermediateWebPlatform
UserClientCreate Link APIComputeLink StoreStorageRedirect CacheStorageRedirect ServiceCompute

The write path stores the mapping in a durable data store and optionally publishes it to a cache; the read path looks up short codes via a fast in-memory or key-value cache and redirects the user if present, otherwise falls back to the store.

When to use it

  • Short links need fast redirect latency and a simple, low-cost write path
  • You can tolerate a cache miss occasionally, or refresh aggressively with a low TTL

Trade-offs

  • A cache miss adds latency and can increase load on the store during a burst
  • A short TTL can cause a hot link to bounce between store and cache frequently

Components used

Web AppManaged App ServiceKey-Value StoreCache

How it works

  • Creating a link generates a short unique key — from a counter encoded in base62, or a hash with collision checking — and stores the mapping.
  • Redirects are overwhelmingly the dominant operation, so the read path is a cache lookup that rarely touches the database.
  • The response is an HTTP redirect, and the choice between 301 and 302 determines whether analytics are still possible.

Used in the wild

  • Link shortening for social posts and SMS where characters are limited.
  • Trackable campaign links with click attribution.
  • Stable short aliases in front of long, changeable internal URLs.

Good to know

  • Use 302, not 301. A permanent redirect is cached by the browser forever, meaning you never see the second click and can never repoint the link.
  • It is the classic system design interview question because it looks trivial and then forces conversations about key generation, cache strategy, read/write skew and hot keys.