Every feed request hammers the DB. Put a cache in front and watch the hit-ratio climb and DB load collapse — then feel the catch when stale data is served until the cache expires.
ChatSphere's trending feed is read constantly. Press play with the cache off and watch the DB take every read; turn the cache on and watch it warm up and shield the database.
Cache hit ratio
0%
DB reads / tick
14
of 14 requests
DB load
100%
Cache contents — warm keys served from memory
feed:0—
feed:1—
feed:2—
feed:3—
feed:4—
feed:5—
No cache — every single read hits the database.
The catch: stale cache
Database (truth)
v1
Served from cache
v1
Update the database and the cache keeps serving the old value until you invalidate it or its TTL expires. That gap is the price of caching.
Where caches actually live
🌐
Browser cache
on the user's own device
0 msmiss → down
🛰️
CDN
edge servers near the user
~20 msmiss → down
⚡
App cache · Redis
in-memory key–value store — lives in RAM, not a file or a DB
~2 ms✓ served here
🗄️
Database
on disk — the source of truth
~80 msnot reached
A read falls through the layers until something has it. Hot feed is served at App cache · Redis — the database is never even touched. Note: an app cache like Redis is just an in-memory key–value store (RAM), not another database and not a file. A CDN caches at the edge; the browser caches on the device.
What just happened
▹A cache sits in front of the database and answers repeated reads from memory. For a hot path — a trending feed hit thousands of times — most reads never touch the DB.
▹The cache warms up: the first read of a key misses and hits the DB, then every later read is a fast hit. Watch the hit ratio climb and DB load collapse once it's warm.
▹The catch is staleness. When the source changes, the cache keeps serving the old value until it expires or is invalidated. Caching trades freshness for speed — fine for a feed, dangerous for a price or balance.