Home › Scenarios › URL shortener
System design scenario
Design a URL shortener (like TinyURL or bit.ly)
Warm-up
A read-heavy redirect service (99% reads). Short codes are hot and cacheable; writes create new links.
▶ Simulate this designThe goal
Keep p99 < 200 ms and error rate < 0.10% at 1,000,000 req/s for 10s.
- Peak load
- 1,000,000 requests per second
- Traffic mix
- 99% reads, 1% writes
- p99 latency
- under 200 ms
- Error rate
- under 0.10%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- Edge LB (Load Balancer, 4 instances): Edge load balancer: terminates TLS and spreads requests across the redirect API fleet.
- Redirect API (Service, 40 instances): Stateless redirect API: resolves a short code to its long URL and answers 301/302; also creates new codes.
- Links DB (Database): Source of truth for code → URL mappings. Every redirect currently reads from here, so it is the hot spot.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- Redirect lookups are read-mostly: put a cache in front of the database.
- Add read replicas so cache misses do not overwhelm the primary.
- Scale the API tier: each instance tops out around 5k req/s.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator