First of all:
There are only two hard things in Computer Science: cache invalidation and naming things. See full post
In our application, we use Redis
as an in-memory cache server. We store customer information with composite key customer_CustomerGUID
. Our strategy is:
For example the Customer
table.
- We have some endpoints where we provide data from the cache (suppose
GetCustomerInformation
). - In our business codes, when we update customer information, we invalidate the cache value of that specific customer.
In this way, we can serve the latest data from the cache every time we update in real-time.
Now Problem is, the code base is growing and developers also. So new developers or any developer often forget to invalidate customer cache when update customer information and there are a lot of places from where customer information is being updated. Furthermore, invalidate cache code segment should not be in business class from the design perspective(I guess).
We thought several approaches like adding an interceptor when we call SaveChanges with EF (we use entity framework), adding HandlerAttribute
on those endpoints which potential to change customer information or other approaches also. But none of those is convincing from a simplicity perspective.
Our whole application resides on Azure Services
. We are deciding to use Azure Logic Apps
and Azure Functions
to invalidate the cache. When customer information updates Azure Logic Apps
will call an Azure Function and that azure function will invalidate the cache of that customer.
Is this approach is good enough to implement or Is there any other good approach in our situation.