Fix the design · Incident triage
Broken Short Links: The Redirect That Sent Users Nowhere
During a cricket World Cup campaign on bit.ly, one viral short link drove about 50× traffic, causing about 95% cache misses, redirect waits up to about 8 seconds, and saturated database replicas.
You are on bit.ly’s redirect team during a cricket World Cup campaign. A viral link drives about 50× traffic to one short URL. Cache misses hit about 95% and redirects take up to about 8 seconds.
We need your help. Identify the bottlenecks and failure modes in the current design, then redesign the path from “browser opens a short link” → “redirect completes” so one viral code cannot stampede the origin, analytics stay off the critical path, and other redirects remain fast.
Problem
Redesign bit.ly’s existing redirect path — it already looks up each short code in Redis first, then PostgreSQL on a miss, and records a click on every redirect.
Incident summary
- A viral marketing link drove about 50× normal traffic to a single short code.
- Cache miss rate for that code hit about 95%.
- Redirect waits reached about 8 seconds at worst; about 18% of requests failed.
- PostgreSQL read replicas maxed out on disk reads.
- Click analytics ran on every redirect and added extra writes on the hot path.
Assumptions made by the team
- Cache hit rate stays above 99%.
- One hot URL is rare.
- Writing analytics on every redirect is a small cost.
- Database replicas can scale reads without limit.
Impacted services
- Redirect API (critical) — Slow and failing under the viral short code.
- Redis cache (degraded) — Miss rate for the hot code hit about 95%.
- PostgreSQL replicas (critical) — Disk reads maxed out on the same hot lookups.
- Customers (critical) — About 18% of redirects failed; others waited up to about 8 seconds.
Triage questions
- Why does this read path fail when one short code gets almost all the traffic?
- How would you redesign redirects to survive a viral link without maxing out the database?
- How would you protect a single hot URL from slowing down every other redirect?
- Does tracking click analytics on the hot path make this problem worse?