URL Shortener Design

URL Shortener Design is a case-study chapter for designing a URL shortener at large scale. The objective is to move from requirements to APIs, capacity estimates, storage choices, cache strategy, scaling strategy, and failure handling.

API Design

• POST /urls creates a short code for a long URL
• GET /{code} redirects to the long URL
• GET /urls/{code}/stats returns click analytics

Capacity Estimation

• Reads usually dominate writes because redirects are frequent
• Estimate redirect RPS, new URL writes per day, mapping size, and click event volume
• Design redirect path for very low p99 latency

Database Selection

• Use a key-value or relational table keyed by short code
• Store code, long_url, owner_id, created_at, expiry, and status
• Use append-only analytics storage for click events

Cache Layer

• Cache code to long_url mappings in Redis
• Use CDN or edge cache for extremely hot public redirects when safe
• Expire or invalidate cache when a URL is disabled

Load Balancing

• Route redirects through global load balancers
• Keep redirect services stateless
• Use health checks to remove unhealthy instances

Sharding Strategy

• Shard by short code hash
• Avoid sequential code ranges that create hot partitions
• Keep analytics partitioned by code and time

Replication Strategy

• Replicate mapping data for high read availability
• Use asynchronous analytics pipelines for click events
• Route critical admin reads to primary if immediate consistency is required

Failure Handling

• Serve cached mappings if the database is briefly unavailable
• Fail closed for disabled or abusive links
• Buffer analytics events when the stream is slow

Real Production Considerations

• Abuse detection and phishing takedowns are essential
• Redirect latency is the product experience
• Analytics accuracy can be eventually consistent

Design a URL shortener so users get a fast and reliable experience while writes, reads, media, fanout, location updates, or stream metadata grow independently. The design must explain the first practical architecture and the path to scale it without losing operational control.

• Expose APIs for the core user workflow
• Persist authoritative business data
• Serve read-heavy views with acceptable freshness
• Support asynchronous background processing
• Provide moderation, abuse prevention, or operational repair paths where needed

• Low p99 latency for interactive reads
• High availability during regional or dependency failures
• Durable writes and recoverable workflows
• Horizontal scaling for hot paths
• Observable request traces across services

The high-level architecture uses edge routing, stateless API services, domain services, durable storage, cache layers, asynchronous workers, event streams, and observability.

Core entities: ShortUrl, LongUrl, User, ClickEvent, AbuseRecord.

• Create request validates URL and user quota
• Service generates or reserves a unique code
• Mapping is stored in the database and optionally warmed in cache
• Redirect request checks cache, falls back to DB, then returns 301 or 302
• Click event is published asynchronously

• Use a key-value or relational table keyed by short code
• Store code, long_url, owner_id, created_at, expiry, and status
• Use append-only analytics storage for click events

• Cache code to long_url mappings in Redis
• Use CDN or edge cache for extremely hot public redirects when safe
• Expire or invalidate cache when a URL is disabled

• Route redirects through global load balancers
• Keep redirect services stateless
• Use health checks to remove unhealthy instances
• Shard by short code hash
• Avoid sequential code ranges that create hot partitions
• Keep analytics partitioned by code and time
• Replicate mapping data for high read availability
• Use asynchronous analytics pipelines for click events
• Route critical admin reads to primary if immediate consistency is required

1. What is the first design for URL Shortener Design?

Answer: Start with API services, durable storage, cache for hot reads, asynchronous workers for heavy tasks, and a load balancer.

1. How do you scale the design?

Answer: Identify hot reads, hot writes, large objects, fanout, and regional traffic, then add caches, queues, sharding, replicas, and regional routing deliberately.

1. What should you discuss after drawing the diagram?

Answer: Discuss capacity, database selection, cache invalidation, sharding, replication, failure handling, observability, and tradeoffs.