Practice/Oracle/Design a URL Shortener

Design a URL Shortener

System DesignMust

Problem Statement

Design a URL shortening service similar to TinyURL or Bitly that allows users to convert long URLs into short, shareable links and manage their shortened URLs. Users paste a long URL, receive a compact code like https://sho.rt/Ab3Cd, and anyone visiting that short link is redirected to the original address.

The system looks simple but exercises core distributed systems skills: globally unique ID generation without collisions, extreme read scaling for redirects, low latency at the edge, write-heavy analytics capture, abuse prevention, and solid data modeling. Interviewers want to see crisp requirements, scale estimation, appropriate storage and caching strategy, and pragmatic tradeoffs around availability, consistency, and cost.

Key Requirements

Functional

Create short links -- users submit a long URL and receive a unique short code that maps to it
Redirect -- visitors hitting a short link are redirected to the original URL with minimal latency
Link management -- authenticated users can view, disable, delete, and optionally update the destination of their links
Basic analytics -- users can see total clicks, time series data, referrers, and geographic distribution for each link

Non-Functional

Scalability -- support billions of stored links and handle redirect traffic orders of magnitude higher than creation traffic
Reliability -- achieve 99.99% availability for redirects since broken links directly impact user trust
Latency -- serve redirects in under 50ms at the edge using cached lookups
Consistency -- strong consistency for link creation (no duplicate codes); eventual consistency acceptable for analytics

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Short Code Generation Strategy

Interviewers want to understand how you generate globally unique, collision-free short codes at scale without creating bottlenecks.

Hints to consider:

Use base62 encoding (a-z, A-Z, 0-9) for URL-safe short codes; 7 characters yield 3.5 trillion unique codes
Consider pre-allocated ID ranges per server to avoid coordination on every creation
Evaluate hash-based approaches (MD5/SHA truncation) versus counter-based approaches and their collision tradeoffs
Discuss why base62 is preferred over base64 (avoiding URL-unsafe characters like + and /)

2. Read-Heavy Redirect Path

Redirect traffic is overwhelmingly read-heavy. Interviewers expect aggressive caching and edge distribution strategies.

Hints to consider:

Place a Redis cache in front of the database for hot short codes with sub-millisecond lookups
Use CDN edge caching with appropriate cache-control headers for popular links
Implement multi-tier caching: edge CDN, regional Redis clusters, then database as fallback
Handle cache invalidation when users update or disable links

3. Analytics Pipeline Design

Every redirect generates an analytics event. Interviewers want to see how you capture this data without slowing down the redirect path.

Hints to consider:

Decouple analytics from the redirect path by publishing click events to a message queue asynchronously
Use Kafka to buffer click events and downstream stream processors to aggregate counts, time series, and geographic data
Never perform synchronous database writes for analytics on the redirect hot path
Consider approximate counting (HyperLogLog) for unique visitor counts to reduce storage costs

4. Abuse Prevention and Edge Cases

URL shorteners are commonly abused for phishing, spam, and malware distribution. Interviewers probe your awareness of these concerns.

Hints to consider:

Implement URL validation and scanning against known malware/phishing databases on creation
Apply rate limiting per user and per IP to prevent bulk creation abuse
Support link expiration and automatic disabling of flagged links
Consider how to handle the same long URL submitted multiple times (return existing code or create new ones)

Practice/Oracle/Design a URL Shortener

Design a URL Shortener

System DesignMust

Problem Statement

Key Requirements

Functional

Create short links -- users submit a long URL and receive a unique short code that maps to it
Redirect -- visitors hitting a short link are redirected to the original URL with minimal latency
Link management -- authenticated users can view, disable, delete, and optionally update the destination of their links
Basic analytics -- users can see total clicks, time series data, referrers, and geographic distribution for each link

Non-Functional

Scalability -- support billions of stored links and handle redirect traffic orders of magnitude higher than creation traffic
Reliability -- achieve 99.99% availability for redirects since broken links directly impact user trust
Latency -- serve redirects in under 50ms at the edge using cached lookups
Consistency -- strong consistency for link creation (no duplicate codes); eventual consistency acceptable for analytics

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Short Code Generation Strategy

Interviewers want to understand how you generate globally unique, collision-free short codes at scale without creating bottlenecks.

Hints to consider:

Use base62 encoding (a-z, A-Z, 0-9) for URL-safe short codes; 7 characters yield 3.5 trillion unique codes
Consider pre-allocated ID ranges per server to avoid coordination on every creation
Evaluate hash-based approaches (MD5/SHA truncation) versus counter-based approaches and their collision tradeoffs
Discuss why base62 is preferred over base64 (avoiding URL-unsafe characters like + and /)

2. Read-Heavy Redirect Path

Redirect traffic is overwhelmingly read-heavy. Interviewers expect aggressive caching and edge distribution strategies.

Hints to consider:

Place a Redis cache in front of the database for hot short codes with sub-millisecond lookups
Use CDN edge caching with appropriate cache-control headers for popular links
Implement multi-tier caching: edge CDN, regional Redis clusters, then database as fallback
Handle cache invalidation when users update or disable links

3. Analytics Pipeline Design

Every redirect generates an analytics event. Interviewers want to see how you capture this data without slowing down the redirect path.

Hints to consider:

Decouple analytics from the redirect path by publishing click events to a message queue asynchronously
Use Kafka to buffer click events and downstream stream processors to aggregate counts, time series, and geographic data
Never perform synchronous database writes for analytics on the redirect hot path
Consider approximate counting (HyperLogLog) for unique visitor counts to reduce storage costs

4. Abuse Prevention and Edge Cases

URL shorteners are commonly abused for phishing, spam, and malware distribution. Interviewers probe your awareness of these concerns.

Hints to consider:

Implement URL validation and scanning against known malware/phishing databases on creation
Apply rate limiting per user and per IP to prevent bulk creation abuse
Support link expiration and automatic disabling of flagged links
Consider how to handle the same long URL submitted multiple times (return existing code or create new ones)