System Design

URL Shortener

Design a URL shortener like TinyURL or Bitly.

Functional requirements

• Given a long URL, generate and return a unique short link (e.g., short.ly/aB3xK9).
• Redirect anyone who visits a short link to the original long URL.
• Support optional custom aliases chosen by the user (e.g., short.ly/my-launch), rejecting duplicates.
• Support optional expiration times on links; expired links return a 404/410.
• Track basic per-link click counts viewable by the link creator.

Non-functional requirements

• Redirects are the critical path: p99 redirect latency under 100ms (excluding the destination site's load time).
• High availability for redirects: prioritize availability over strict consistency for reads; a newly created link may take a few seconds to become globally readable, but an existing link must never redirect to the wrong destination.
• Short link creation must be strongly consistent for uniqueness: two users can never end up owning the same short code.
• Once created, a mapping is durable: losing a mapping breaks published links permanently and is unacceptable.
• Short codes should not be trivially enumerable/guessable to protect private links.

Scaling & constraints

• 100M new short links created per month.
• Read:write ratio is roughly 100:1 (redirects vs. creations).
• Average stored record (short code + long URL + metadata) is ~500 bytes; long URLs average ~200 bytes and can be up to 2KB.
• Links are retained for 5 years by default; assume steady growth of ~20% per year in creation volume.
• Traffic is highly skewed: the top ~10% of links receive ~90% of redirect traffic, and freshly created links spike immediately after being shared.

Out of scope

• User account management, authentication, and billing.
• Malware/phishing scanning of destination URLs.
• Rich analytics dashboards (geo, referrer breakdowns) beyond raw click counts.
• Link preview generation and QR codes.