shrt.design

Core Data Flow

Redirection (Read Path)

How does GET /{code} resolve fast at massive read volume, without falling over on a viral link?

Redis302 FoundCDN / Edge CacheConsistent Hashing
ClientRedirectHandlerDatabase

Click a node to see what it does. Switch tiers above to see how the design scales.

Overview

This is the hottest path in the entire system. Redirects outnumber link creations by orders of magnitude, so this is the subsystem that forces the caching conversation — and it’s the natural centerpiece of a URL shortener interview, the same way a home timeline read is for a feed product.

API Design

GET /{code}
// 302 Found
Location: https://example.com/some/very/long/path

Why 302, not 301: a 301 (Moved Permanently) lets browsers cache the redirect indefinitely — faster on repeat visits, but the server never sees that click again, which kills click analytics outright. A 302 (Found) forces the browser back to the server on every single visit. A Bitly-style shortener deliberately uses 302 for exactly this reason: the analytics is the product, and it only exists if every click is observable.

Basic Approach — Direct Database Lookup

How it works

Every request looks up the code directly in the primary database and redirects to whatever long_url comes back.

Client ──▶ Redirect Handler ──▶ Database lookup by short_code ──▶ 302 Location: long_url

Tradeoffs

  • Pro: Always perfectly consistent — a link created a millisecond ago redirects correctly immediately.
  • Con: Every redirect is a database read. At real traffic volumes, where reads vastly outnumber writes, this single lookup becomes the whole system’s primary bottleneck and single point of failure.

Scaled Approach — Cache-Aside with Redis

How it works

The handler checks Redis first. On a hit, it redirects without touching the database at all. On a miss, it falls back to the database, then populates the cache so the next request for that code is fast.

Client ──▶ Redirect Handler ──▶ Redis (cache) ──hit──▶ 302
                                        └──miss──▶ Database ──▶ populate Redis ──▶ 302

Tradeoffs

  • Pro: The overwhelming majority of redirects — the hot links — never touch the database, which now only serves cold or rare codes.
  • Pro: Redis’s in-memory reads are orders of magnitude faster than a disk-backed lookup, directly cutting redirect latency.
  • Con: Cache invalidation — a deleted or edited link can keep redirecting to the old target until the stale entry is evicted or explicitly purged.
  • Con: A cold cache (e.g., right after a deploy) briefly sends a spike of traffic straight to the database until it’s repopulated.

Advanced Approach — Edge/CDN Redirects + Consistent Hashing

How it works

Push redirect resolution to edge locations physically close to the requester, so a cached redirect never has to cross the network back to a single origin region. The origin cache tier itself scales out across multiple nodes using consistent hashing on short_code, so adding or removing cache nodes reshuffles only a small fraction of keys instead of invalidating the whole cache.

Client (anywhere) ──▶ Nearest Edge Node (cache) ──hit──▶ 302 (no origin round-trip)
                              └──miss──▶ Origin Cache Ring (consistent hashing) ──hit──▶ 302
                                                └──miss──▶ Database ──▶ populate ring + edge

Tradeoffs

  • Pro: Redirect latency becomes dominated by network distance to the nearest edge node rather than any single origin server’s load — this is what lets a viral link’s global traffic spike land without the origin even noticing.
  • Pro: Consistent hashing means scaling the cache tier up or down doesn’t trigger a full cache-wide miss storm, unlike a naive mod-N hash.
  • Con: Stale mappings can now linger across many edge locations, not just one Redis instance — invalidation has to propagate everywhere.
  • Con: Meaningfully more operational surface area — edge compute, cache-ring rebalancing, and multi-region consistency each fail independently.

Tech Choices

  • Redis — sub-millisecond cache-aside lookups for the hot path.
  • 302 Found — deliberately not 301, to keep every click observable.
  • CDN / edge compute (e.g., Cloudflare Workers) — moves redirect resolution physically closer to users.
  • Consistent hashing — lets the cache tier scale without mass invalidation.

How to Vocalize This in an Interview

This is the subsystem where “reads vastly outnumber writes” pays off hardest — say that fact out loud before drawing a single box, and let it justify caching before the interviewer has to ask why. Bring up 301 vs 302 unprompted; it’s a small, concrete detail that signals you’ve thought about this as a real product, not a generic system design exercise.