I am considering a scheme for passing a timestamp value in a cached response, and then sending it back to the service to perform cache invalidation. I'm wondering if that's a valid approach. Is that a common approach?

For example, if I have a service that returns a "Foo" record, which is a combination of DB lookups and calculations. Let's say Foo is identified with a key. To speed things up, I want to keep a local cache of results.

The problem is, across a bank of servers, the local caches will get out of sync, because the calculated results will change over time.

So my thought is:

  • for a request, calculate a Foo
  • store the Foo in local cache with an "as of" timestamp
  • return the Foo along with the "as of" timestamp
  • when the client wants to fetch a Foo, it passes the key as well as the "as of" timestamp.
  • if the server finds the key in the local cache, and the "as of" timestamp in cache is newer than the "as of" parameter, return the cached Foo with the Foo, key and "as of" timestamp
  • otherwise recalculate the Foo, cache it, and return the (new) Foo, key and (new) "as of" timestamp

The client would need to keep track of both the key and the "as of" timestamp, but then it would essentially control when service instances refresh their local cache, without the service instances talking to each other or some back-end storage for coordination.

If the client wanted to force a cache refresh, it could pass "as of" of max value, which would force a refresh on any service instance it hits.

Certainly I could put a caching layer in front of my service, and I could also save results in a distributed cache. Those solutions have their own data replication and expiration issues too. But for the purpose of this question, I really want to consider local caching & consider the architectural questions separately.

Q: Does that work? Is it valid or good to use a timestamp parameter as a mechanism for cache invalidation?

  • Cache can be configured with evict period as usual. And this period can be configured for cache in general (not for single element). So if you need to catch evict event with dynamic time for each element you should not use cache but different approach. Scheduler can cover your wishes (I prefer crone based frameworks because of very flexible dynamic tooling).
    – Serhii
    Commented Jun 25, 2017 at 7:31

1 Answer 1


Local caching is simpler to implement. The issues to watch out for are:

  1. Multiple cache misses during the cache population event.
  2. Cache population fails.
  3. Depending on which server the request hits will return a different answer.

With .NET I handled the cache miss problem by having the cache store the Task<> asynchronous wrapper, and using locking to ensure that only one Task<> to obtain the cached value was created. This worked well.

When the process to obtain the cache value fails, what does your application do? Does it cache the failure returning the error until the cache expires? Or do you create a new attempt to obtain the value?

When you have a multiple servers with independent caches and the underlying values changing regularly the answer will depend entirely on which server handles that request. This may not be an issue in your application, but think long and hard about what this means for your user and their confidence in your competence. If you keep getting conflicting data it can undermine trust.

Implementing a distributed cache with riak and key expiration solves many of these issues when you have multiple application servers. However it does not solve the cache population issue, when multiple threads on multiple servers all decide that the cache needs re-populating.

  • Good considerations, and your final comment about Riak is apt. I suppose what I'm considering is an expiring key scheme, if you consider the combination of "key + as of" to be a sort of expiring key. However, I'll never reach the level of functionality Riak provides ;)
    – sea-rob
    Commented Oct 7, 2015 at 18:33
  • 1
    I would either embed the expires time logic into your cache implementation, or (if using a standard hashmap class, I would create a meta value, storing the cache data about the value, as well as the value) Commented Oct 8, 2015 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.