mardi 11 juillet 2023

Correct design pattern for invalidating cache after service bus event

Let's say I have two applications: Web API, and Web UI. They are both using the same product database. The business case is very read-intensive (via API) with rare writes (via Web UI). Therefore on the API side there exists singleton ProductCatalog service, which holds most of the active parts in memory as object graph and applies business logic rules to serve read requests. When someone use WebUI to make changes in catalog, I want to update/invalidate the cache inside this service. I will use service bus (Azure Service Bus) to propagate this event.

What is the correct design pattern on Web API side to do this?

  • it feels bad for ProductCatalog to implement subscription to service bus
  • it also feels weird to expose some InvalidateCache method on this service to be called by someone else
  • should there be some component to encapsulate service bus subscriber, and expose incoming messages as regular .NET events? Should this component be therefore dependency (injected) of ProductCatalog, so it can subscribe to these events?

Is there some good example of .NET implementation of something like this?

Aucun commentaire:

Enregistrer un commentaire