Video explanation
This cache-aside model connects a client, an application server, Redis, and PostgreSQL. The server checks Redis first: a hit returns a cached value, while a miss queries the database and fills the cache. Colored signals, cache slots, a TTL dial, and an event log follow the sequence from miss to fill, hit, write invalidation, and another miss, alongside expiration and cache flushing.
Hit and miss paths
A hit returns a value from Redis without querying the database. On a miss, the application reads the database and caches the result. The fast and slow paths visualize these cases; the shown latency values are simulation parameters.
TTL and expiration
A key’s time to live limits its lifetime. After expiration, a new request misses and reloads it. Shorter TTLs limit stale-data retention but may increase database reads; TTL alone does not guarantee freshness.
Invalidation after a write
WRITE + DEL updates the underlying data and removes its cached key. The next read reloads it from the database. Concurrent reads and writes can still race, so this animation is not a complete consistency protocol.
Capacity and flushing
The model shows a finite set of cache slots. Real Redis memory limits and eviction policies are configurable. Flushing the cache causes subsequent reads to return to the database; flushing, expiration, deletion, and memory-pressure eviction are different operations.