Implement cache support in service fabric

0
votes

I am working on a project in which I will be calling Service Fabric methods and returning the data to end user. The Data is modified very infrequently or is almost constant so I want to maintain a cache and return it if the data is not modified.

The project structure is: WepApi(Stateless Service) -> Repository -> SatefulService

What is the best way of implementing this in Azure Service Fabric? I am thinking of two options:

  1. Redis cache a. Creating a Redis cache project where it will expose two endpoints for storing and getting cache data. This project will be referenced in the repository layer. b. Creating a Redis cache service( service fabric ) and calling from the repository.
  2. stateful service a. Creating a separate dictionary in the existing stateful service and use it for getting and storing data.

And, I am also having below questions.

Approach #1:

  1. We have to depend on 3rd party system(Redis cache) and we might not get accurate results if the server is not available.

Approach #2:

  1. We might get a performance issue if the cache data is increased over time.

Any best approaches to implement a cache in service fabric?

Thanks,

1
azurecachingazure-service-fabricazure-redis-cache
We might get a performance issue if the cache data is increased over time. -> why? what is the reason behind this assumption? The only drawback I see is that out of the box there is no cache eviction – Peter Bons
What data are we talking about? What amount / size? – Peter Bons
I might get a list of records and count would be maxing of 10000 records. Each record might have 10 - 20 properties – Balanjaneyulu K
I execute a linq query on two collections and store it in Redis or collection. The data which I store might be one record or multiple records. – Balanjaneyulu K
Have you thought about .net memory cache ? docs.microsoft.com/en-us/aspnet/core/performance/caching/… – Rahul Ruikar

1 Answers

1
votes

Reliable Collections were designed for performance, bc they run in-process and data is kept in memory if there is enough available memory (which in your case should be ok, for ten thousand records). The only slow-down compared to a regular dictionary in memory is that a reliable dictionary must maintain transactional consistency while reading, but i presume you need this consistency anyway?