You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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,
The text was updated successfully, but these errors were encountered:
If the data is relatively static, then there is not really a concern for perf hits in your Approach #2 question. Using a machine-local reliable store (like a reliable dictionary) will be as performant as you can get given there is no network traversal involved for reads and writes... Plus, the data will be persisted and synchronized across nodes automatically (thus the notion of data being reliable).
The only cost here is disk IO, which will be minimal for data on disk that seldom changes (so, many more reads than writes...). Not sure you have much of a choice to make since you already employ a stateful app. Just use a reliable dictionary and move on to harder problems :-)
Thanks for the info. You mean to say, store the cache data in a reliable dictionary and get the data?
We can store the data in a reliable dictionary but we may get performance issues and may not be the correct place to store cache data. (Correct me if I am wrong)?
Perhaps I don't fully understand your scenario. Are you talking about CDN-like content caching? What is wrong with Redis or some other caching service? I was assuming you already employ reliable stateful services. If the idea is to cache content that you serve to requests, then the standard approach applies and has little to do with Service Fabric since it would be an external service that manages your cache. Can you supply more details of the exact problem?
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,
The text was updated successfully, but these errors were encountered: