Caching Layer

Overview

Redirection already leans on Redis, but caching deserves its own page: what eviction policy to use, what happens when a cache node fills up or a link suddenly goes viral, and how to avoid ever serving a cold cache miss on the moment traffic spikes hardest. Interviewers frequently probe this as its own topic rather than a detail buried inside the redirect flow.

Basic Approach — Cache-Aside, No Eviction Policy

How it works

Same lookup-then-populate pattern as Redirection’s scaled tier, but the cache grows unbounded — every code ever looked up stays cached forever.

Redirect Handler ──▶ Redis (check) ──miss──▶ Database ──▶ write to Redis (no TTL, no eviction) ──▶ 302

Tradeoffs

• Pro: Once a code is cached, it’s cached forever — zero repeat-miss cost for that code, ever again.
• Con: An unbounded cache eventually exhausts available memory — nothing distinguishes a link hit constantly from one clicked once three years ago that will never be clicked again.

Scaled Approach — TTL + LRU Eviction

How it works

Cached entries get a time-to-live, so stale data self-heals even without explicit invalidation, and the cache is capped at a fixed memory size, evicting the Least Recently Used entry once it’s full.

Redirect Handler ──▶ Redis (LRU cache, TTL per entry) ──miss──▶ Database ──▶ write with TTL ──▶ 302

Tradeoffs

• Pro: Memory usage stays bounded and predictable regardless of total link count — the cache naturally holds “whatever’s popular right now.”
• Pro: A TTL means an edited link self-corrects within one window even if explicit invalidation is ever missed.
• Con: A link that suddenly goes viral after being cold still causes a brief burst of cache misses right as traffic spikes — exactly the moment a miss is least affordable.
• Con: Choosing the TTL is a real tradeoff — too short and popular links keep hitting the database; too long and edits or deletes take longer to propagate.

Advanced Approach — Write-Through Cache + Hot-Key Replication

How it works

Instead of only populating the cache reactively on a miss, the write path (URL Shortening) writes the new mapping into the cache at creation time — so a link is cache-warm before its first click ever arrives. Separately, keys that get disproportionately hot are detected and replicated across multiple cache nodes, so one viral link can’t overwhelm a single node while its neighbors sit idle.

URL-Shortening write ──▶ writes to Database AND Redis simultaneously (write-through)
Redirect Handler ──▶ Redis ──hit (always, for new + popular links)──▶ 302
Hot-Key Detector ──▶ replicates an overloaded key across N cache nodes ──▶ load spread across replicas

Tradeoffs

• Pro: Eliminates the cold-link miss entirely for anything created through the normal write path — only truly ancient, never-looked-up links ever fall back to a database read.
• Pro: Hot-key replication stops one viral link from single-handedly saturating one cache node.
• Con: Write-through means every write does double duty (database + cache) even for links that may never be clicked — wasted cache memory for links that never take off.
• Con: Detecting a key is “hot” and replicating it is itself a small distributed system — it needs its own monitoring and thresholds, and can lag a true traffic spike by a few seconds.

Tech Choices

• Redis — in-memory store with native TTL and LRU/LFU eviction.
• Write-through caching — keeps newly created links warm from the first request.
• CDN edge caching — pushes the cache tier physically closer to users (ties into Redirection’s advanced tier).

How to Vocalize This in an Interview

Caching is the single highest-leverage sentence in this whole design — say “reads outnumber writes by orders of magnitude” early and often, since it’s the one fact that justifies almost every scaling decision in this guide. Save hot-key replication for when the interviewer asks “what happens when one link goes viral?”