Name: System Design Masterclass
Availability: InStock

Cache-aside is how nearly every cache in nearly every codebase is used. The application checks the cache, and on a miss it fetches from the source and stores the result itself. Nothing sits between the application and either the cache or the database.

A sequence diagram between the application, the cache and the database. The application asks whether user:42 is in the cache. The cache says no. The application fetches it from the database itself. Then it stores it in the cache itself and returns it, noted as four calls, all of them written by you. — SequenceFigure 1. The application asks, and on a miss it fetches and stores the result itself
That is the definition of the pattern and it is also every one of its properties, good and bad. The cache knows nothing about the database and cannot load anything on its own.

Five rows. The key, computed at every call site independently. The fetch, and its timeout and retries. The store, and the serialisation and TTL. The failure path, meaning what happens when the cache is unreachable. And the invalidation, which the cache-invalidation lesson covered. — FigureFigure 2. Five things the pattern hands to your application
Every description of cache-aside lists the first three. The fourth is where the pattern's most-repeated advantage actually lives, and it does not exist unless somebody writes it.

The claim is that cache-aside degrades gracefully when the cache fails, because the cache is not on the critical path. The application simply talks to the database and carries on.

A terminal capture of the cache-aside outage lab. 2,000 requests a second for 170 seconds at a 94 percent hit rate against a database that can serve 260 reads a second, with the cache unreachable from second 30 to 50. A table of four policies against requests served, failed, success during the outage, database reads during the outage and seconds to recover. Read-through and fail closed both give 0.0 percent. Fail open gives 13.0 percent. Shed gives 12.0 percent. Findings follow. — terminal-figureFigure 3. The measurement. Four failure behaviours across a twenty second cache outage
Read-through and unwrapped cache-aside answered nothing at all. Cache-aside with the cache call in a try block answered 13.0 percent of requests.

A bar chart with four bars. Read-through gives 0.0 percent of requests answered during the outage, cache-aside unwrapped gives 0.0, cache-aside with fail open gives 13.0, and the database's own capacity share is 13.0. — ChartFigure 4. Unwrapped cache-aside and read-through both answered nothing at all
The third and fourth bars being identical is the finding. The fallback did not deliver resilience, it delivered the database's capacity.

A sequence diagram between the application, an unreachable cache and the database. The application asks whether user:42 is in the cache. The cache refuses the connection. If this is not caught, the request ends here. If it is caught, the application asks the database instead, noted as measured 0.0 percent against 13.0 percent of requests answered. — SequenceFigure 5. The pattern does not provide the fallback. A try block provides the fallback
A cache client throws on a connection failure like any other network call, and nothing about cache-aside catches that exception for you.

Read your own cache-aside code and find the failure path. If there is no try around the cache call, the application does not degrade to the database when the cache fails, it fails with the cache.

Where this shows up in interviews

Where this shows up in interviews

Cache-Aside Pattern

The rest of this lesson

Continue this lesson

The Application Does All Four Steps

The Advantage It Is Sold On, Measured