SysPad › Examples › URL shortener
URL shortener
Cache-aside redirect reads (app servers → Redis → DB on miss), a dedicated base62 ID-generator on the write path, and an async click stream feeding an analytics lake.
The read/write split - a heavily-skewed redirect read path kept off the database by cache, ID minting as its own service, and click analytics decoupled onto a stream.
- Load: 20,000 req/sec
- First to saturate: Click Stream
- Estimated cost: $51k/mo
How it works
- Redirect Cache
- Redirect traffic is enormously skewed toward a few hot links, so most lookups end here and never reach the database. This is what makes reads cheap.
- ID Generator (base62)
- Mints a unique base62 short code on write so concurrent shorten requests never collide: a dedicated key-minting step rather than a random-and-retry in the app.
Request flows
Follow short link
- Client
- DNS
- Load Balancer
- App Servers
- Redirect Cache
- URL Database
Shorten a URL
- Client
- DNS
- Load Balancer
- App Servers
- ID Generator (base62)
- URL Database
- Redirect Cache
Click analytics
- Client
- DNS
- Load Balancer
- App Servers
- Click Stream
- Click Aggregator
- Analytics Lake
Lessons for this architecture
- Modelling users and traffic entry points
- How Route 53 works
- How Application Load Balancer works
- How ECS Fargate works
- How Amazon ElastiCache works
- How AWS Lambda works
- How DynamoDB works
- How Kinesis Data Streams works
- How S3 works
Worked step by step
The same interview question, built up one twist at a time, with a simulation at each stage.