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 the 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 as 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 afterwards) 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...