Just as using Hazelcast to provide a distributed caching layer in front of our traditional database, we can also invert this relationship. By having Hazelcast as the primary data store we can configure MapStore to provide long term persistence of stored objects, working around the potential risk of data resilience due to Hazelcast's in-memory nature.
This resilience, however, does come at a cost to performance and scalability. This means that we have to update an external system upon each change to the cluster data. However, we can configure the method of this process between synchronous (where data is written out to the store prior to returning confirmation to the client), or asynchronous (where this process happens in the background shortly after) through the use of the write-delay-seconds configuration. A zero value indicates synchronous persistence and a positive value determines the delay before the asynchronous process kicks in.
So an example map configuration...
