0

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.

  • 1
    "Is this a common approach?" Not that I know of, but it doesn't matter if that is your specific requirement. "Is there a more standard approach?" Yes... Failover sites. But you might not be able to afford that. – Robert Harvey Apr 6 '18 at 16:43
  • 1
    ^what he said. this isnt caching its an odd fail over solution – Ewan Apr 6 '18 at 20:11
  • what is your data source? – Ewan Apr 6 '18 at 20:12
  • @Ewan We're using Fredhopper and Microsoft SQL. If Fredhopper fails, it takes a while to rebuild or resolve to get back up and running. We've also been tripped up with bugs in Fredhopper and we don't want to be at the mercy of their code failing which brings our site down completely and instantly. We'd want to keep serving traffic. Thanks for your comments. – Luke Apr 7 '18 at 9:11
  • 1
    This becomes more manageable if you put it in an interceptor (Windsor, Unity, etc.) On the happy path the interceptor stores results in the cache and returns them. If the invocation throws an exception it checks the cache and if it can find a result there, it logs the exception and returns the cached result. The interceptor keeps that logic out of your controller. I wouldn't intercept at the http request level. I'd put it around the data source. That way most of your application isn't even aware of the behavior. – Scott Hannen Apr 10 '18 at 19:05
1

The closest thing that can still scale, is using "Circuit Breakers with Fallbacks" pattern. Check on Netflix's Hystrix https://github.com/Netflix/Hystrix/wiki/How-it-Works which is one implementation of such pattern

Here's one of their blogs where they explain the general benefits https://medium.com/netflix-techblog/making-the-netflix-api-more-resilient-a8ec62159c2d

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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