Cache Access Patterns

Here’s a quick summary of the patterns and the context they best fit in:

In a read-through pattern, applications request data directly from the caching system, and if the data exists in the cache, that data is returned to the application. If the data does not exist (a “cache miss”), then the system retrieves the data from the backend store. The system then loads that data into the cache and returns the data to the backend store.

In a write-through pattern, applications can directly update data in the cache, and whenever that is done, the updated data is synchronously and automatically persisted to the backend data store. This pattern is about ensuring the cache and backend store are synchronized and is not intended to address performance (performance is addressed with the write-behind cache pattern, described below) since the backend store is still the bottleneck in an update process.

In a write-behind pattern, applications can update data in the cache similarly to the write-through cache pattern, except the automatic updates to the backend store are asynchronous. This means this pattern offers a performance advantage since updates to the data do not have to wait for writes to the backend store. Updates to data in the cache are acknowledged quickly since only in-memory data is updated, and Hazelcast will later push the data updates to the backend store.

Near cache is highly recommended for data structures that are mostly read. When an object is fetched from a remote cache, it is inserted into the local cache, so subsequent requests are handled by the client retrieving from the local cache.

In a refresh-ahead cache pattern, data is proactively retrieved from the backend store so that application requests for data will be served from the cache. This pattern front-loads the cache with anticipated data so that the application doesn’t have to wait for the backend store to retrieve data. The better you can predict which data will be requested, the more efficient this pattern works. At the same time, if the prediction is off, then that will result in retrieving an incorrect amount of data which will impact the effectiveness of the cache. Too much retrieved data can result in overloading the cache which causes more cache misses by other application requests, and too little retrieved data will require a read-through pattern that forces the application to wait for the backend store.

Hazelcast Platform is an ideal caching platform because it supports all the caching patterns above to simplify your application development effort. Instead of writing application logic to manage data in both the cache and the backend store, you only need to focus on data access to a Hazelcast cluster. Let the cluster manage data accesses to and from the backend store.

Not only does Hazelcast Platform support your caching requirements, but its breadth of distributed computing capabilities gives you room to grow for future use cases. You can build even more advanced applications that deliver speed and responsiveness without having to bolt on other external technologies and server clusters. The simplified architecture reduces coding and maintenance complexity, to speed up your time-to-market and realize ROI faster, and while reducing your TCO and downtime.

Traditional caching: For your basic caching needs, Hazelcast handles the entire read/write process so your application does not need to coordinate reads from the backend store upon cache misses. To establish the link between Hazelcast and the backend store, application developers write pluggable query code that is executed by Hazelcast in the event of a cache miss.

Near cache: Hazelcast includes near cache capabilities to give users a huge advantage over NoSQL solutions like Redis, Cassandra, MongoDB, etc., which do not have near caching capabilities. In benchmark comparisons, Hazelcast is already 56% faster than Redis without using near cache. Enabling near cache makes Hazelcast 5 times faster than Redis. If Hazelcast near cache features in client-server deployments are being used, microsecond response times can be achieved with the right serialization.

Refresh-ahead cache: Hazelcast supports this pattern with its built-in distributed computing engine. You can write server-side applications that run as continuous jobs in the Hazelcast cluster that look for data accesses that are used to predict future reads. For example, if an application requests profile information for a customer, the Hazelcast jobs can retrieve all other customer information based on that customer’s historical data access patterns, and retrieve that information proactively so that subsequent requests from the application will leverage the proactively cached data. Hazelcast also provides change data capture (CDC) capabilities so that data updates in the backend store by a separate application can be proactively propagated to the cache.

Both of the aforementioned examples of refresh-ahead caching can be done in Hazelcast Platform without needing any other external technology.