Cache Invalidation

Warning: You are browsing the documentation for Symfony 5.x, which is no longer maintained.

Read the updated version of this page for Symfony 7.2 (the current stable version).

Cache invalidation is the process of removing all cached items related to a change in the state of your model. The most basic kind of invalidation is direct item deletion. But when the state of a primary resource has spread across several cached items, keeping them in sync can be difficult.

The Symfony Cache component provides two mechanisms to help solve this problem:

Using Cache Tags

To benefit from tags-based invalidation, you need to attach the proper tags to each cached item. Each tag is a plain string identifier that you can use at any time to trigger the removal of all items associated with this tag.

To attach tags to cached items, you need to use the tag() method that is implemented by cache items:

1
2
3
4
5
6
7
8
$item = $cache->get('cache_key', function (ItemInterface $item) {
    // [...]
    // add one or more tags
    $item->tag('tag_1');
    $item->tag(['tag_2', 'tag_3']);

    return $cachedValue;
});

If $cache implements TagAwareCacheInterface, you can invalidate the cached items by calling invalidateTags():

1
2
3
4
5
// invalidate all items related to `tag_1` or `tag_3`
$cache->invalidateTags(['tag_1', 'tag_3']);

// if you know the cache key, you can also delete the item directly
$cache->delete('cache_key');

Using tag invalidation is very useful when tracking cache keys becomes difficult.

Tag Aware Adapters

To store tags, you need to wrap a cache adapter with the TagAwareAdapter class or implement TagAwareCacheInterface and its invalidateTags() method.

Note

When using a Redis backend, consider using RedisTagAwareAdapter which is optimized for this purpose. When using filesystem, likewise consider to use FilesystemTagAwareAdapter.

The TagAwareAdapter class implements instantaneous invalidation (time complexity is O(N) where N is the number of invalidated tags). It needs one or two cache adapters: the first required one is used to store cached items; the second optional one is used to store tags and their invalidation version number (conceptually similar to their latest invalidation date). When only one adapter is used, items and tags are all stored in the same place. By using two adapters, you can e.g. store some big cached items on the filesystem or in the database and keep tags in a Redis database to sync all your fronts and have very fast invalidation checks:

1
2
3
4
5
6
7
8
9
10
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
use Symfony\Component\Cache\Adapter\RedisAdapter;
use Symfony\Component\Cache\Adapter\TagAwareAdapter;

$cache = new TagAwareAdapter(
    // Adapter for cached items
    new FilesystemAdapter(),
    // Adapter for tags
    new RedisAdapter('redis://localhost')
);

Note

TagAwareAdapter implements PruneableInterface, enabling manual pruning of expired cache entries by calling its prune() method (assuming the wrapped adapter itself implements PruneableInterface).

Using Cache Expiration

If your data is valid only for a limited period of time, you can specify their lifetime or their expiration date with the PSR-6 interface, as explained in the Cache Items article.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version