> Can you give an example?
Imagin a user with _administrator_ role. The guy can access every protected resource in the site with that role, and therefore a cache starts to build up. We have to assume worst case scenario, permanent lifetime cache. That means that if that particular user is demoted to be _authenticated user_ he would still have access to the protected resources because they are in his cache –as long as the entity doesn't get updated causing cache invalidation–.

Another example would be a user updating his preferences changing the language negotiation for an entity translated api.
> Explain? invalidation the entire cache whenever a user is saved.
We have a `DrupalCacheInterface` that we use to interact with the different cache backends. One of the methods on that is `DrupalCacheInterface::clear($cid, $wildcard)`. According to the docs you can easily remove every cache record whose cache id that starts with a string `$cid`. Note the *starting with* part. There is no way to tell the cache implementation _hey you! bust all cache entries that *contain* this particular string_. Or I have never been able to find one (if you don't hack into backend specific implementations).

> sounds quite harsh.
Agreed. Should we scan the cache bin manually to compare cache ids using PHP? Sounds costy but it won't run very often…