System Design Lab

A URL shortener is a read-heavy key-value lookup that outgrows one box from the read side first.

Change redirect and create rates, how many links are stored, hot-link skew, the short-code length, latency target, and regions. The design moves from a single database to cache-aside reads, a dedicated key-generation strategy, a sharded KV store, and multi-region edge redirects.

Read the full tutorial

Guided walkthrough

Reason about it one step at a time

Normal evolution scenarios

Click left to right for the intended demo path. Each card changes the workload inputs.

Workload

These are inputs, not preset architecture stages.

Redirect rate Reads: short code looked up and 301/302 returned. This is the dominant traffic. Create rate Writes: new long URLs submitted to be shortened. Stored links Total short-code to long-URL mappings kept in the system. Hot-link share Share of redirects that target the small set of currently popular links. Short-code length Characters in the base62 code. Keyspace is 62^length. Redirect latency target Budget for resolving a short code before the redirect is sent. Regions Regions that should serve redirects close to the user. Track click analytics Record each redirect for dashboards; should not slow the redirect itself. Allow custom aliases Let users pick their own code; rules out a pure auto-increment counter.

Recommended shape

Current architecture path

Clients

Client follows short links and submits new long URLs to shorten

Edge / API

Edge / CDN resolves hot redirects close to the user without hitting the origin

App server looks up codes for redirects and handles create requests

Keys + cache

Key service hands out collision-free short codes (ranges, Snowflake, or pre-generated keys)

Read cache serves code to URL lookups for popular links so the store is spared

Mapping store

Mapping DB durable store of every short code and its long URL

KV shards spreads mappings across nodes for storage and write throughput

Analytics

Click stream collects redirect events for dashboards off the hot path

Bottlenecks

Read path load

Write path load

Mapping storage

Code keyspace fill

Global redirect latency

Why this changes

Decision tradeoffs

Read cache

Code generation

Mapping store

Storage sharding

Edge redirects

Click analytics

Source-backed rules

These are the durable system-design claims behind the model. The exact slider thresholds are deliberately labeled as teaching assumptions.

Verified rule

A URL shortener is dominated by reads (redirects), not writes

The canonical write-up treats redirect lookups as the high-volume path and link creation as comparatively rare, which is why read scaling comes first.

System Design Primer

Verified rule

Cache-aside keeps hot reads off the database

The cache-aside pattern loads items into a cache on demand; for skewed redirect traffic a small cache absorbs most lookups.

Azure Architecture

Verified rule

Redis is a common in-memory store for hot key-value lookups

In-memory point lookups serve popular short codes at sub-millisecond latency, far below a disk-backed store.

Redis Docs

Verified rule

A CDN serves cacheable responses from locations near the user

Redirects for popular links are cacheable at the edge, cutting cross-region round trips for a global audience.

AWS CloudFront

Teaching assumptions

Redirects are modeled as cacheable point lookups; cache hit rate is approximated from the hot-link share.
Single-node read, write, and storage budgets are conservative teaching numbers, not vendor limits.
Code keyspace fill uses base62^length; real systems also reserve key ranges per ID server to avoid collisions.