The following considerations should be taken into account while implementing this pattern:

• Isolation levels: While using this pattern, the isolation levels suited for the application need to be chosen based on characteristics of transactions. More about isolation levels supported by Reliable Collections can be found at: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-reliable-collections-transactions-locks.
• Persistence: The persistence model required by the reliable data sore needs to be accounted for, before implementing this pattern. The frequency of write, replication, batching I/O operations, and so on are few things to consider while choosing a persistence model.
• Timeouts: It's important to introduce timeouts for every call associated with a reliable data store to avoid dead locks.
• High availability: To ensure high availability, consider running multiple instances of your Microservice at a time. Microsoft recommends at least three instances of a service to be active at any time.
• Synchronization delay: Where there are multiple instances of Microservices deployed, the data store on one of the instances will act as a primary and others would be considered as secondary. In case of an update, there will be a delay in reflecting changes across secondary instances of the data store. This may lead to chances of read operations retrieving stale data.