Search code examples
cachingazure-web-app-servicememcachedblazor-server-side

What is the best approach to caching a very long list of rarely changed data?

This is for a Blazor server app running on Azure. In the app there are a lot of times a user will be selecting a couple of tags from a very long list. The content of that list rarely changes and when it does, only this same app changes it so it can update the entry in the list at the same time.

This is like the tags here on Stack Overflow. The entire list is queried so often, you want a global List<Tag> in memory.

Which brings up two questions. The first is these tags will generally be passed to DxTagBox. While a page is being edited by the user, and DxTagBox is applying filters to that list to determine what to show, it can be changed (Create/Update only - no Deletes).

I've got a question in to DevEx, but assuming DxTagBox wants an immutable list, what's the best approach? The best I've come up with is I have a static list and a live list. The static list is passed to DxTagBox and the live list is updated. Every N minutes I copy the live list to the static list for any future needs and let garbage collection determine when to free up the now orphaned list. I'm not wild on this approach, but it's the best I've come up with.

The second question is: How do I copy changes between servers when I have multiple servers? Would Redis work well here? Should I broadcast messages to all the other servers with each CRUD action? Should I just re-read everything from the database every N minutes?

Update: Yes, DxTagBox wants a complete immutable list.

Solution

  • My take on this is:

    1. "One Version of the Truth" across multiple servers equals a database table.
    2. Add a timestamp to each entry so you can do a quick query to check if any records have recently changed. Saves blindly pulling the list when you don't need to.
    3. "The content of that list rarely changes" so check for new timestamps every x seconds in a Singleton Service.
    4. Read the data into immutable objects with no tracking [I assume you are using EF]. Your POCO is a record not a class.
    5. Define your individual filters for display as IEnumerables against the singleton list and only materialize them when you consume them (in the DXTagBox). Don't create intermediate lists.