We have a REST web service written in C# in ASP.NET MVC/WebAPI.
When the underlying data store fails, this can lead to our service being completely unavailable, instantly. There is currently no caching of data in the service. We're exploring caching patterns, however I have a feeling that our approach isn't going to be conventional - or that's what I think from researching these patterns so far.
We want to:
- Cache the HTTP responses from our service to an in memory cache (such as Redis).
- Update the cache with every successful request (200 OK).
- Allow the cache to live indefinitely, so that during a data store outage, it would continue to respond to requests by returning the last good response from the cache.
- Only use the cache when the request to the data store fails, or another there's another error that returns a response other than 200 OK to the consumer.
Is this a common approach for caching in a web service, or is there another more standard approach that we could employ to achieve the same effect?
The main difference in this approach from what I could consider to be a 'normal' caching approach, is that the response is cached for every successful request, but the cached value is only actually used and returned when a request would otherwise fail.
We would like as many requests to use the up to date data, as the data changes quite frequently, which is why our caching approach can't just be 'Cache this for 10 mins and return the same response for each request'. This also wouldn't allow us breathing space to resolve the issues with our data store before the cache ran out.
It sounds like a good idea to us, because this would allow us some breathing space when our data source fails, but I'm wondering if there could be some serious caveat(s) to this approach?
Thank you for your thoughts on this caching approach.
