Feature: Add cache key deletion support based on collection UID and slug, with optional key tagging

[sehrish30]

Hi 👋 and thank you for the great work on this plugin!

Right now, the plugin stores cache keys based on the full request path, like:

GET:/api/blogs/blog%2Fjournal?locale=en-us

However, when deleting or updating an entity from a collection like api::blog.blog, the cache keys are not properly invalidated because they are tied to the request URL, while the mutation event typically only provides access to the entity ID.

I'd love to see support for cache key deletion that can be triggered based on:

1. The collection UID (e.g., api::blog.blog)
2. A key field (e.g., slug)

This would allow us to delete request-based cache entries tied to an entity even if the keys don't include the entity ID.

Inspiration from strapi-provider-rest-cache-redis

In strapi-provider-rest-cache-redis, each request-based cache key was tagged with entity metadata such as:

1. collection:api::blog.blog
2. entity:id:
3. entity:slug:

This allowed the plugin to find and delete all cache entries related to a specific entity when it was updated or deleted — even if those cache keys were built from query strings or slugs

Suggested Improvement

When saving a cache key, optionally tag it with related metadata (collection UID, entity ID, and slug if applicable). On entity mutation, allow deleting all cache keys that match those tags.

Example flow:

1. Cache key saved:
   key: GET:/api/blogs/blog%2Fjournal?locale=en-us Tags: [api::blog.blog, slug:blog/journal]

2. On deletion of blog/journal:
   Automatically remove all cache keys tagged with slug:blog/journal and api::blog.blog

Use Case

If I delete a blog with the slug blog/journal, I want the plugin to automatically remove keys like:
GET:/api/blogs/blog%2Fjournal?locale=en-us

[TupiC]

Hi, thank you for the feature request. Sounds really interesting.

1. What exactly do you mean with:

However, when deleting or updating an entity from a collection like api::blog.blog, the cache keys are not properly invalidated because they are tied to the request URL, while the mutation event typically only provides access to the entity ID.

When you delete a blog entry all cache entries with blogs in it should get invalidated/removed. If this is not the case please give me a more detailed explaination on what does not get purged. Which keys do get invalidated and which ones do not get invalidated?

2. If this feature gets implemented should it only get used once redis is chosen as provider?
3. If I got you right -> you want to be able to purge cache entries not only based on slug but in general on any attribute a collection/single type might have, right?

[sehrish30]

Hi, thank you for the feature request. Sounds really interesting.

1. What exactly do you mean with:

However, when deleting or updating an entity from a collection like api::blog.blog, the cache keys are not properly invalidated because they are tied to the request URL, while the mutation event typically only provides access to the entity ID.

When you delete a blog entry all cache entries with blogs in it should get invalidated/removed. If this is not the case please give me a more detailed explaination on what does not get purged. Which keys do get invalidated and which ones do not get invalidated?

2. If this feature gets implemented should it only get used once redis is chosen as provider?
3. If I got you right -> you want to be able to purge cache entries not only based on slug but in general on any attribute a collection/single type might have, right?

No strong opinion on that — but it would be great if it worked with any provider (Redis, in-memory, etc.), as long as it supports pattern-based key matching.

Let's start by focusing on slug-based purging first.

I'd suggest supporting a mapping between entity slugs (or IDs) and their corresponding request cache keys. For example, if a cache key looks like

For example, if my cache keys look like:
GET:/api/blogs/bugs%2Fgalore?locale=en-us

And the blog entity has slug = 'bugs/galore', the invalidation flow could:

1. Decode the slug (bugs%2Fgalore → bugs/galore)
2. Match all cache keys that contain that slug in the path
3. Invalidate only the relevant keys.

[TupiC]

I won’t implement purging just for a single attribute (e.g. slug). That use case is too specific and making it work with all attributes later takes more time than implementing it properly upfront. Could you also answer my first question? And which strapi and strapi-cache versions are you using? Thanks😌

[sehrish30]

When you delete a blog entry all cache entries with blogs in it should get invalidated/removed. If this is not the case please give me a more detailed explaination on what does not get purged. Which keys do get invalidated and which ones do not get invalidated?

the broader solution is we use "a tagging system with each cache entry"

For example:
Key: "GET:/api/blogs/bugs%2Fgalore?locale=en-us" Tags: ["api::blog.blog", "slug:bugs/galore", "id:123"....]

when an entity was updated or deleted:

1. It looked up tags like slug:bugs/galore and id=123
2. Then it deleted all keys tagged with those values, even list endpoints or search queries.

this made it robust: all related keys were invalidated, not just the one by ID

One approach could be to let developers declare which attributes should be considered for cache tagging or invalidation, such as slug, handle, or any custom field relevant to their use case.

We cannot include each field of the collection in tags, they should be specific fields like id, slug, uid , locale

cache: { tagFields: ['id', 'slug', 'handle'] // ← similar approach }

[TupiC]

When you delete a blog entry all cache entries with blogs in it should get invalidated/removed. If this is not the case please give me a more detailed explaination on what does not get purged. Which keys do get invalidated and which ones do not get invalidated?

the broader solution is we use "a tagging system with each cache entry"

For example: Key: "GET:/api/blogs/bugs%2Fgalore?locale=en-us" Tags: ["api::blog.blog", "slug:bugs/galore", "id:123"....]

when an entity was updated or deleted:

1. It looked up tags like slug:bugs/galore and id=123
2. Then it deleted all keys tagged with those values, even list endpoints or search queries.

this made it robust: all related keys were invalidated, not just the one by ID

One approach could be to let developers declare which attributes should be considered for cache tagging or invalidation, such as slug, handle, or any custom field relevant to their use case.

We cannot include each field of the collection in tags, they should be specific fields like id, slug, uid , locale

cache: { tagFields: ['id', 'slug', 'handle'] // ← similar approach }

This is does not answer my question at all. I know how to implement that. Thank you for the details. I am asking about the issue with the cache invalidation of the blog entries.
You mentioned:

However, when deleting or updating an entity from a collection like api::blog.blog, the cache keys are not properly invalidated because they are tied to the request URL, while the mutation event typically only provides access to the entity ID.

When a blog entry is deleted which cache entries are invalidated? Are all cache entries with blogs in it invalidated or only specific ones?

[sehrish30]

When a blog entry is deleted which cache entries are invalidated? Are all cache entries with blogs in it invalidated or only specific ones?

When a blog entry is deleted, no cache entries are invalidated in my case because all cache keys are URL-based and do not include the entity ID.

For example, my typical cache key looks like: GET:/api/blogs/bugs%2Fgalore?locale=en-us. Since the cache is organized by URL and not by entity ID, deleting a blog entry using its ID has no effect on the corresponding cache entries.

[TupiC]

Ok, thank you for clarification. Will implement that feature asap and make it optional since not everyone needs something like that.

[sehrish30]

Hi @TupiC , just wanted to check if there are any updates on this issue?

[TupiC]

I have time end of next week to start working on that (will keep you updated)

[sehrish30]

I have time end of next week to start working on that (will keep you updated)

Thank you

[abhijit-hl]

Hey I am also facing the same issue here - While clicking on purge entity cache button in cities entry. It is invalidation cache which includes (Entity ID) But my cache key looks like this:
"GET:/api/cities?filters%5Bcity_name%5D%5B%24eq%5D=ahmedabad&populate%5Bcity_section_info%5D%5Bpopulate%5D=*"
It does contain any ID here.

Suggestion:

There should be configuration to add in the plug like for which slug or attribute to search while invalidating individual entry cache keys.

I have create a issue for the same:
#38