Service Fabric stateful services in-memory vs external storage

Question

I have a Service Fabric application and it contains two services stateless and stateful. Service Fabric Application Stateless Service: It contains API endpoints to communicate with stateful service. Stateful Service: The data is being stored in Reliable collections i.e in-memory storage.

I have around 15 service fabric microservices that will be communicating with each other based on the requirement. I'm ending up with a lot of proxy calls in order to communicate between the services which is one of the major reasons for performance hindrance.

In order to mitigate this issue, I have a thought to remove stateful service( in-memory storage with Reliable Dictionaries) and use external storage like Azure Cosmos DB as a data storage.

In the new approach, my application will have one stateless service and it will communicate with the external data store ( ex: Cosmo DB). Service Fabric Application Stateless Service: It contains API endpoints to communicate with the storage provider ( Ex: CosmosDB).

Can anyone let us know whether Service fabric in-memory or external storage gives more performance?

Apart from the performance issues with the in-memory storage, it is becoming very challenging to implement the complex queries or do any elastic search or creating reports as we have dependencies between the services.

Is there any other better approach that can really resolve these kinds of issues?

Answer 1

Hi @Balanjaneyulu Kantu

It seems like you are trying to implement micro service architecture with reliable storage as your persistence. Also, you have a scenario with service calling another service calling another service. If my previous statements are correct, you need to think about architectural direction in two specific areas

1. What's persistent storage vs. cache - You can get comparable performance from Cosmos when you are accessing using Partition Key and ID directly. If you are planning to search data on Cosmos, unless you plan proper indexing, it may turn out more expensive. Also, choose your database based on how you are consuming the data. If search is your priority then may be Azure Search may be good option. Also, I do not feel comfortable using service fabric reliable storage as persistent storage, rather I look at it more like cache. In summary, look at how you are going to consume the data to determine best storage.
2. Why are the hops? What is velocity of data being queries? If the data being queried is relatively static can you implement service cache to avoid those hops. May be Radis cache can help you get response if configurations are static. When we built the microservice with service fabric, we had a guideline than there should not be more than 3 hops to process any request.

You may want to look CQRS patterns . This pattern allows you to create multiple projections (views) and each view can have different role like reporting, querying (projection), searching (selection).

Thanks

Nandan Mathure