Follow a cache miss all the way down
Cache-aside in front of a database, with the application orchestrating it. A request arrives for a key that isn't cached.
The hops are all drawn. What's easy to get wrong is that the miss travels backwards before it travels forwards — the cache answers first, with nothing, and only then does the database get involved.
Tap the components in the order a cache miss visits them.
?Getting this order backwards is how a cache ends up permanently stale.
Outside every boundary: Cache write (store it with a TTL), Database (has the value), Client (asks for a key), Application (owns the logic), Cache lookup (misses) Connections: Client calls Application — GET key Application calls Cache lookup — cache first Application calls Database — only on a miss Application calls Cache write — then write back
Tap the components in the order a request travels them.