Design a URL Shortener

Design Bit.ly from scratch. Cover hashing strategies, redirect performance, analytics storage, and why this deceptively simple system is a masterclass in read-heavy scaling.

What you will learn

• Choose between hash-based and auto-increment ID strategies and defend the tradeoff
• Design a read-heavy system with 100:1 read/write ratio using layered caching
• Handle custom aliases, expiry, and abuse prevention without killing write throughput
• Separate the hot redirect path from the cold analytics path

URL shorteners look simple — they take a long URL and return a short one. That surface simplicity makes them a favourite interview question. The interesting decisions hide underneath: how to generate IDs at scale, how to serve 100M redirects a day at sub-10ms latency, how to record click analytics without slowing down the redirect, and how to handle expiry, custom aliases, and abuse.

Before touching architecture, narrow the scope. In an interview, ask explicitly.

Functional requirements:

• Given a long URL, return a unique short URL (e.g. https://sho.rt/aB3kX9)
• Visiting the short URL redirects to the original long URL
• Users can optionally supply a custom alias
• Links expire after a configurable TTL (default: never)
• A dashboard shows click counts per link

Non-functional requirements:

• Redirects must be fast — p99 < 10ms
• System must be highly available — a redirect failure is user-visible
• Short codes must be unique — collisions are unacceptable
• Analytics can tolerate eventual consistency (5–10 second lag is fine)

Create a free account to read the full chapter — advanced chapters, progress tracking, and quizzes are free with sign-up.