Live System Design Simulator

URL Shortener — High-Level Design & Live System Simulator

Watch a request travel end-to-end through a real URL shortener architecture. Run the write path, a cache hit, a cache miss, and a Redis failover — then stress it with a traffic burst and read what every hop does.

read-heavy 100:1Redis + sharded KVKGS keys302 + async clicks

speed

Requests

Cache hits

Cache miss

—

Hit ratio

—

Avg latency

QPS (live)

Step log

Ready. Pick a scenario above — the request will animate hop-by-hop.

request write path cache hit / 302 cache miss → DB async click event failure / failover

How to read it: a coloured packet is one request in flight. Nodes glow while they process it. Read = HIT is served straight from Redis (sub-millisecond); MISS falls to the KV DB then back-fills the cache; every redirect fires an async click event to Kafka so the 302 is never blocked. Run Traffic burst to feel the read-heavy load — watch the hit-ratio settle near ~85% and QPS spike, exactly why a cache sits in front of the DB.

Why this design works

A URL shortener is a read-heavy system — redirects outnumber new short-link creations by roughly 100:1. The architecture above optimizes for that skew: a Key Generation Service (KGS) pre-allocates unique keys so writes never need a collision check, Redis absorbs the vast majority of reads in sub-millisecond time, and the sharded KV database is only touched on a cache miss or a new write.

Click analytics are decoupled entirely — every redirect fires a non-blocking event onto Kafka, so the user-facing 302 response is never held up by analytics processing. When Redis fails, the system degrades gracefully by falling through to the database directly, favoring availability over strict consistency (an AP trade-off), so short links keep resolving even during a cache outage.