Unified Cache Keys: How Namespaced Keys Improve Service Interoperability

More than just random keys in a Redis.

Introduction

Developers tend to use cache to store a key / value pair, something that they need their program to remember for a period of time to avoid performing a bigger or slower operation to retrieve data again.

One important feature of caching, is that it shouldn’t be a point of failure. If your cache get flushed, your application should still be running without failing.

Often, cache keys should be expired, either by a mechanism that updates their value or simply by expiring after a period of time. A combination of both is great. That’s to ensure you are not seeing outdated data forever.

Cache keys are usually generated based on known values from the context surrounding the code. Like the URL path and parameters or a user id and it’s order id etc..

The problem

In order to get or invalidate the cached value, you need to recreate the same key that stored it. If you are in the same code path or code context, it’s totally fine, that’s the normal use case of cache.

What about events in your platform that requires to flush composite cache keys ? A composite cache key is a key that is relevant to more than 1 business entity.

Like a user’s dashboard configuration.

Now, in that context, if something changes on the dashboard OR on the user side, you might have to delete, expire or replace that cache key.

So if your code has the user already, you would need to go get the dashboard or vice versa in order to recreate that generated key and act on it.

Another use case would be, when you have multiple services, they might not have the full context like users service doesn’t know about dashboards and probably shouldn’t. Therefore it’s hard for it to expire composite cache keys.