Choose appropriate data

Menus, display configuration and public articles are usually read more often than edited. They are good cache candidates. Access rights, authentication codes and security state need their own consistency mechanisms; do not serve stale security data just to save a few queries.

Define how stale the data may be. For editorial pages, changing content in Admin CP should increase the data version. A cache tied to an old version will no longer be used on the next read.

Handle unavailable caches

A cache is an acceleration layer, not the only source of data. If it restarts or runs out of capacity, the application must still read from the primary source. Appropriate connection timeouts prevent cache faults from slowing every request.

Avoid one huge cache containing the entire website when most pages need only a small part. Grouping data with similar update lifecycles reduces the amount read and the scope of refreshes.

Monitor cold and warm states

A warm-cache measurement does not describe the whole experience. Test the first load after deployment, after content changes and while the cache is temporarily unavailable. Evidence from each case supports better choices for cache lifetime and size.