2

I am very new to Service Fabric.

Is Service Fabric recommends to use only Reliable Collections to store ALL the data for an application?

What if I use SQL DB to persist all my business data and use Reliable Collection to lazily persist to SQL DB for integration purposes. Following DDD, if i persist my aggregate to SQL DB and leave a entry in reliable collection to communicate with other Bounded Context. Will this approach has any issues?

CGSK
  • 43
  • 8

2 Answers2

1

The Service Fabric does NOT recommend to store all the data in Reliable Collections. Its your choice. The Service Fabric provides you freedom on how to do things, on many levels.

You can use an external DB(like SQL DB or DocumentDB or anything) and use the stateful service as a cache. Or use the stateful service as a primary storage and don't use an external DB at all.

Even though the Reliable Collection is a bit limited in usage(its a key/value store with no effective query interface other than looping all the data) it has the advantage of being internally stored(performance) and it has good fail safe mechanisms(defining secondary instances, as many as you want). The partitioning capabilities should not be forgotten either.

Personally I tend to minimize the external dependencies. An external DB is a dependency. But if your requirements for your application specify extensive query capabilities, go for it.

Ashan
  • 18,898
  • 4
  • 47
  • 67
Martin
  • 256
  • 1
  • 7
  • Can you please provide a link where written that SF does not recommend storing of all the data in Reliable Collections? – cassandrad Oct 10 '16 at 15:20
  • Its my english. I meant that there is no obligation to store data in Reliable Collections. Its a choice. Store it in SF or in an external database. – Martin Oct 20 '16 at 06:29
0

According to Microsoft

Treat Reliable Actors as a transactional system. Service Fabric Reliable Actors is not a two phase commit-based system offering ACID. If we do not implement the optional persistence, and the machine the actor is running on dies, its current state will go with it. The actor will be coming up on another node very fast, but unless we have implemented the backing persistence, the state will be gone. However, between leveraging retries, duplicate filtering, and/or idempotent design, you can achieve a high level of reliability and consistency.

https://acom-feature-videos-twitter-card.azurewebsites.net/en-us/documentation/articles/service-fabric-reliable-actors-anti-patterns/

Manas
  • 25
  • 5