> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# URL Shortener The Celebrity Spike and the Cache
> URL shortener caching strategy to absorb celebrity-driven hot key spikes using CDN, Redis, app server caches, and Postgres to minimize database load.
When a celebrity posts one of our short links and millions of people click it in a short timeframe, the system must absorb a sudden burst of reads. This is a classic read-heavy, hot-key problem for URL shorteners.
## Traffic baseline: normal day vs. celebrity hour
Assumptions:
* \~1,000 clicks per short link created.
* 1,000,000 links created per day.
Rough daily reads:
1,000,000 links × 1,000 reads/link = 1,000,000,000 redirects/day
Spread evenly:
1,000,000,000 requests / 86,400 seconds ≈ 11,574 reads/sec
Table — traffic summary
| Metric | Value |
| - | - |
| Short links created / day | 1,000,000 |
| Reads / short link (avg) | 1,000 |
| Total redirect requests / day | 1,000,000,000 |
| Avg reads / second (24h) | \~11,574 |
Even if a well-tuned Postgres instance might handle tens of thousands of reads/sec, this is a lot for a single DB host — and most of those reads are identical lookups that never change. For example, if 1,000 users click the same short URL, the DB returns the same long URL 1,000 times. That is wasteful.
Example mapping:
```text theme={null}
aX9dQ2z ? -> kodekloud.com/cour… x 1,000
urls
short_code long_url
aX9dQ2z kodekloud.com/cour…
b7Kp1Rz kodekloud.com/blog…
Qm4xT8w kodekloud.com/pric…
hT2vN9c kodekloud.com/labs…
```
Now imagine the celebrity spike: a million clicks in the first hour (or even hundreds of millions globally in a day). Almost all those requests ask for the same short code. This “one thing goes viral and is accessed by many” pattern is called a hot key. Hot keys are the signature failure mode of read-heavy systems.
## Solution: add a cache for hot keys
We should avoid sending a million identical queries to Postgres. Add a fast in-memory cache (for example, Redis) to serve hot keys in under a millisecond.
Typical request flow for a redirect:
1. Client requests the short URL.
2. Request hits the application server.
3. Application server checks Redis:
* Cache hit: return the long URL immediately (no DB involved).
* Cache miss: read from Postgres once, write the mapping into Redis, return the long URL.
4. Subsequent requests for the same short code are served from Redis.
In a celebrity spike, the first request triggers one DB read; the remaining millions are cache hits.
## Staleness concerns
A common cache problem is staleness: the cache can contain outdated data while the database has been updated (e.g., cache has `x = 7`, DB has `x = 9`). That can cause incorrect responses.
In a URL shortener the mapping from short code to long URL is written once and never updated. That makes this workload ideal for aggressive caching: the cache will not serve incorrect data for these mappings.
Note: Because our design treats short codes as immutable (written once, never edited), staleness is not a practical issue for the core redirect mapping. This immutability is important to state in interviews: it justifies aggressive caching.
Also remember caches have finite memory and use eviction policies. Redis typically evicts least-recently-used items to make room. Popular links remain cached; inactive links are removed — which is the desired behavior.
## Further optimizations: push hot keys closer to users
If Redis becomes a bottleneck or you want even lower latency, add additional layers:
1. Application-server local cache
* Each app server keeps a small in-process LRU cache (e.g., top few thousand links).
* Extremely hot links are served directly from app memory with minimal latency.
2. Content Delivery Network (CDN)
* Place a CDN in front of the service so geographically nearby nodes can answer redirect requests.
* Regional CDN nodes absorb massive global spikes; on a cache miss they fall back to the origin.
## Cache layers and responsibilities
| Layer | Purpose | Typical technology / note |
| - | - | - |
| CDN | Absorb global spike and reduce latency | CDN edge caches; TTL can be short since mappings are immutable |
| App-server in-memory cache | Ultra-low-latency for hottest keys | Process LRU cache (top N entries) |
| Redis | Primary shared cache for hot keys | Fast in-memory store; backs cache misses to DB |
| Postgres | Durable source of truth | Read once on cache miss; writes occur on short-link creation |
## Operational considerations
* TTL and eviction: set reasonable TTLs or rely on LRU eviction for Redis since mappings are immutable.
* Cache warming: pre-populate cache for anticipated viral links (if known).
* Monitoring & scaling: alert on cache miss rate, Redis CPU/network, and DB read rate to detect cascade failures early.
* Rate-limiting: protect origin DB with rate limits or request-shedding for extreme spikes.
Even with immutable short codes, ensure your CDN and caches honor expected TTLs or cache-control headers so you can retire or rotate links if necessary (for example, in legal takedown situations).
## Putting it all together: recommended stack
* Use Redis as the primary cache for hot keys to avoid repeated Postgres reads.
* Keep a small LRU cache in each app server for the most popular short codes.
* Front the system with a CDN so regional requests are handled close to the user.
These layers — CDN, edge/app-server in-memory cache, and Redis — allow your URL shortener to absorb celebrity spikes efficiently while keeping database load minimal.
## Links and references
* [Postgres](https://www.postgresql.org/)
* [Redis](https://redis.io/)
* [CDN fundamentals](https://en.wikipedia.org/wiki/Content_delivery_network)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.