Ten Million Keys, One Missing Index

The article discusses how using a per-entity index can improve Redis cache invalidation by reducing the need for large-scale key scans. The problem arises when a cache sits in front of a slower dependency, such as a third-party API or a service with rate limits. When a cache lookup fails, the cache must remove all invalidated data associated with that entity.

The entity identifier is located within the middle of the key, and the service prefix varies, making it difficult to construct key names based on the given information. To delete an entity's cached state, one must first discover its cached key strings and then remove them. The issue becomes more complex when the cache is used to handle failures from the origin, as redis executes commands on a single thread.

For example, using the KEYS command to search for records matching an invalidation pattern across a dataset containing millions of keys can block the Redis thread for seconds, causing delays for other requests. The article demonstrates this issue with a decorator handling caching around a method that calls a billing provider. The decorator fetches the cached read of a user's subscription, and a CacheKey decorator is used to configure the cache.

The key combines the service, tenant, category, entity ID, and parameters, separated by a delimiter. The problem lies in the fact that the key is generated by the read path and must be reconstructed by the delete path, with only the read path having access to the arguments.