A URL shortener looks simple on the surface, but underneath it is a case about an extremely hot read path, short-id generation, and cheap redirects at scale.
This case helps separate the write path that creates short codes from the read path that resolves them: cache hit ratio, storage lookups, hot keys, and resilient edge serving all matter.
For interviews and architecture discussions, it is valuable because it quickly reveals whether you can spot read-write asymmetry, identify the real bottleneck, and avoid premature complexity.
Control Plane
Focus on policy, limits, routing, and stable edge behavior under variable load.
Data Path
Keep latency and throughput predictable while traffic and burst pressure increase.
Failure Modes
Cover fail-open/fail-close behavior, graceful degradation, and safe fallback paths.
Ops Ready
Show monitoring for saturation, retry storms, and practical operational guardrails.
URL Shortener (TinyURL, bit.ly) is a classic System Design interview task. It is ideal for beginners, as it combines a simple concept with interesting architectural solutions: generating unique IDs, scaling the database, and handling high read loads.
Chapter 8
Alex Xu: URL Shortener
Detailed analysis in the book System Design Interview
Why do you need a URL Shortener?
Convenience
Short links are easier to remember, share on social networks and use in SMS
Analytics
Tracking clicks, user geography and traffic sources
Control
Ability to disable a link, set an expiration date or password
Requirements
Functional
- FR1Creating a short link from a long URL
- FR2Redirect via short link to original URL
- FR3Optional TTL (link lifetime)
- FR4Custom alias (optional)
Non-functional
- NFR1100M new URLs per day (write)
- NFR210:1 read/write ratio → 1B redirects/day
- NFR3Latency < 100ms for redirect
- NFR499.9% availability
Back of the Envelope
Traffic
- Write: 100M/day = 1,160 QPS
- Read: 1B/day = 11,600 QPS
- Peak: ~23,000 QPS (2x average)
Storage
- Avg URL size: 500 bytes
- 100M × 500B = 50GB/day
- 5 years: 50GB × 365 × 5 ≈ 90TB
Short URL length
How many characters are needed for a unique identifier? We use base62 (a-z, A-Z, 0-9):
| Length | Combinations | URLs (5 years) |
|---|---|---|
| 6 characters | 62⁶ = 56.8B | Not enough |
| 7 characters | 62⁷ = 3.5T | ✓ Enough |
| 8 characters | 62⁸ = 218T | With reserve |
Conclusion: 7 base62 characters = 3.5 trillion combinations. At 100M URL/day it will last for 96 years.
ID generation strategies
1Hash + Collision Resolution
MD5/SHA256 from URL → take first 7 characters → check for collision
- Deterministic (same URL = same hash)
- No central point of failure
- Collisions require retry + DB lookup
- Difficulty with custom aliases
2Unique ID Generator + Base62Recommended
Get unique numeric ID → convert to base62
- Guaranteed unique (no collisions)
- Simple logic
- Easy to support custom aliases
- Need ID generator (single point?)
- Identical URLs can give different short URLs
ID Generator options
Auto-increment DB
Simple solution with auto_increment primary key.
⚠️ Single point of failure, does not scale
Multi-master DB
Two servers: one generates even IDs, the other generates odd ones.
✓ Easy scaling, but limited by number of masters
UUID
128-bit unique identifier generated on the client.
⚠️ Too long (36 characters), bad for URL
Snowflake IDRecommended
64-bit ID: timestamp + datacenter + machine + sequence.
✓ Distributed, time-sorted, compact
Snowflake
Twitter/X: Snowflake ID
Detailed analysis of the ID generation algorithm
High-Level Architecture
Architecture Map
Browser / App
Edge routing
Stateless API
Read path
Redis
PostgreSQL / Cassandra
Write path
Snowflake
PostgreSQL / Cassandra
Highlight a flow
Cache miss shown as a dashed line to the database.
Write Path
- 1. The client sends a long URL
- 2. ID Generator produces a unique ID
- 3. Convert ID to base62 → short URL
- 4. Save mapping in DB
- 5. Return short URL to the client
Read Path
- 1. The client requests a short URL
- 2. Check Cache (Redis)
- 3. Cache miss → query to DB
- 4. Update Cache
- 5. HTTP 301/302 Redirect
301 vs 302 Redirect
301 Moved Permanently
The browser caches the redirect. The following requests go directly to the target URL.
✓ Less load on the server
✗ Clicks cannot be tracked
302 FoundRecommended
The browser does NOT cache. Every click goes through the server.
✓ Full click analytics
✓ You can change the target URL
Data Model
urls table
| Column | Type | Description |
|---|---|---|
| short_url | VARCHAR(7) | Primary key, base62 encoded |
| original_url | TEXT | Original long URL |
| user_id | BIGINT | Link creator (optional) |
| created_at | TIMESTAMP | Creation date |
| expires_at | TIMESTAMP | TTL (null = unlimited) |
Deep Dive
Database Internals
Indexes, B-Trees and optimization for read-heavy workloads
Caching Strategy
A Read/Write ratio of 10:1 makes caching critical. We use Redis to store hot URLs.
Strategy
- Cache-aside: read from cache, if miss goes to DB
- LRU eviction: evict rarely used URLs
- Write-through: when creating, we immediately write to the cache
Cache Size
20% daily reads × avg URL size
= 200M × 500B = 100GB
→ Redis cluster with replication
CDN
Content Delivery Network
Geo-distributed caching for global systems
Selecting a Database
PostgreSQL
- ✓ ACID guarantees
- ✓ Easy to use
- ✓ Good for medium loads
- ✗ Horizontal scaling is more difficult
Cassandra / DynamoDBFor scale
- ✓ Linear horizontal scaling
- ✓ High availability (no single point)
- ✓ Optimized for write-heavy
- ✗ Eventually consistent
Key takeaways from the interview
Show understanding
• Base62 encoding and URL length calculation
• Trade-offs between hash and ID generator
• 301 vs 302 for analytics
• Read-heavy system → focus on caching
Frequent follow-up questions
• How to handle duplicate URLs?
• How to implement custom aliases?
• How to remove expired URLs?
• How to protect yourself from abuse?
Related chapters
- Design principles for scalable systems - provides latency/throughput baselines to evaluate URL shortener trade-offs as traffic grows.
- Caching strategies: Cache-Aside, Read-Through, Write-Through, Write-Back - expands the read-heavy part of the case: hit rate, invalidation, and cache-pattern selection for redirects.
- Rate Limiter - covers protecting shorten/redirect APIs from abuse, bots, and burst traffic.
- Replication and sharding - explains how to scale short->long mapping storage as data size and QPS increase.
- API Gateway - adds the edge API layer: routing, auth, rate limits, and external policy enforcement.
- CDN - extends the topic to global delivery and edge caching for faster redirects across regions.
- System Design Interview — An Insider's Guide - contains the classic TinyURL interview breakdown with a step-by-step solution flow.