SysPadExamples › 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.

Client Users DNS Route 53 Load Balancer ALB App Servers Fargate Redirect Cache ElastiCache ID Generator (base6… Lambda URL Database DynamoDB Click Stream Kinesis AT LIMIT Click Aggregator Lambda Analytics Lake S3

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

  1. Client
  2. DNS
  3. Load Balancer
  4. App Servers
  5. Redirect Cache
  6. URL Database

Shorten a URL

  1. Client
  2. DNS
  3. Load Balancer
  4. App Servers
  5. ID Generator (base62)
  6. URL Database
  7. Redirect Cache

Click analytics

  1. Client
  2. DNS
  3. Load Balancer
  4. App Servers
  5. Click Stream
  6. Click Aggregator
  7. Analytics Lake

Other interview practice

Open this architecture in SysPad · All examples