The Runtime Theory

Cache-Aside Read Flow: Hit, Miss, and Populate

Walk the cache-aside read path: the cache check, the miss that falls through to the database, and the populate step that makes the next read fast.

The Runtime Theory Team09 stages

trace / request.md

READ REQUESTARRIVESCACHE ISCHECKED FIRSTFRESH VALUERETURNSKEY IS ABSENTDATABASEPAYS THE COSTVALUE ISWRITTEN BACKRESPONSE REACHESTHE CLIENTNEXT READS HITTTL STARTS THECYCLE AGAIN

readyA read request arrives at the application. Cache-aside is application-driven: the service owns the caching logic, deciding when to check the cache and when to populate it.

Cache-aside is the simplest caching pattern and the one most systems actually run: the application checks the cache first, falls through to the database on a miss, and writes the result back. This diagram is the read path in full — hit, miss, populate, expire. What makes it work is that the application owns every decision: when to check, what TTL to set, when to invalidate. The cache is a dumb key-value store and the application is the intelligence around it.

The ordering is a performance story. The cache check is cheap and the database query is expensive, so the flow is arranged to take the cheap path as often as possible. The miss path — stages four through seven — is the entire cost, and the TTL is the clock that governs how often it repeats. The pattern's known failure modes all live in the write path: without invalidation or a short TTL, stale reads are guaranteed.