Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement cache support in service fabric #315

Open
balukantu opened this issue Apr 3, 2019 · 3 comments
Open

Implement cache support in service fabric #315

balukantu opened this issue Apr 3, 2019 · 3 comments
Labels
status-last6months status-olderthan1year Created earlier than current year and no activity

Comments

@balukantu
Copy link

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,

@GitTorre
Copy link
Member

GitTorre commented Apr 12, 2019

Hi,

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 :-)

...Charles

@balukantu
Copy link
Author

Hi Charles,

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)?

@GitTorre
Copy link
Member

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?

@ghost ghost added the status-olderthan1year Created earlier than current year and no activity label Sep 1, 2020
@ghost ghost added the status-last6months label Dec 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status-last6months status-olderthan1year Created earlier than current year and no activity
Projects
None yet
Development

No branches or pull requests

2 participants