Why IMDG

Hazelcast can be used as an in-line database cache. This means developers can continue to work with familiar data structure APIs in their own languages without having to resort to SQL or a NoSQL-specific API. Hazelcast takes care of read-through and write-through to the database at the backend. Read performance is improved to microseconds for cached data and writes to slow databases can be offloaded from the caller and saved to the database asynchronously. Hazelcast does not require the use of a cache aside pattern. Cache aside is required when using NoSQL solutions such as Redis. This generally means the developer must code for cache concerns such as read-through on a cache miss and write-through for saves. Cache aside patterns are also slower as they require more network hops.

Hazelcast Near Caches can be used to store frequently read data within the Application process itself. This means that any Java, .Net, Node.js, Python, C++ or Go programs can reduce their data lookup times from seconds over the network down to microseconds. Hazelcast Near Caches provide their own eviction and memory management facilities so you can be sure your application is safe. The same comments on cache aside mentioned in database caching are true for this use case, let Hazelcast take care of the caching flow, don’t write this logic into your own application.

Hazelcast clusters make excellent platforms for microservice messaging, coordination, and distribution. Hazelcast can facilitate many microservice patterns such as Saga, Datastore per Service, Shared Datastore & CQRS. Hazelcast’s concurrency primitives also provide useful API to coordinate access to services and provide HA services. Hazelcast Topics and Queues can be used to share events across a cluster of Hazelcast-enabled microservices. Hazelcast solves many of the platform challenges of microservices that would usually require separate database, messaging, and coordination software. Robust coordination primitives that can survive network partitions are crucial for microservices. Hazelcast’s concurrency packages are based on a CP subsystem that uses RAFT under the covers.

Hazelcast can be used to deliver a CAAS (Cache-as-a-Service), typically used where various applications need to share similar business data. Or when not shared, a CAAS makes sense to organizations that want to centralize and rationalize the number of data stores that applications have to connect to. A CAAS can (at the same time) sit over many different legacy data stores such as mainframes, relational databases, and NoSQL databases. Many different business areas and application teams make use of the same central CAAS. Because Hazelcast is schema-less and uses sensible defaults, teams can quickly save data to the CAAS without lengthy onboarding processes.

A popular use case for Hazelcast is the caching of web sessions. Web and application servers can easily be made to scale out to handle huge loads by adding devices such as a load balancer. This has a second effect of providing redundancy. However, for applications that use web sessions, this introduces a new problem. If a server goes down and the load balancer moves the user to a new server, the session is lost. Hazelcast stores the web session in its Distributed cache and provides easy to use native adapters for some of the most popular web servers such as Tomcat and Jetty or any other Java-based server via our generic filter based adapter.

NoSQL solutions such as Redis and MongoDB are hugely popular and provide a good fit for many use cases. However, consider using Hazelcast when you are finding NoSQL software is becoming hard to live with, especially when trying to scale and manage in general. Hazelcast has been designed as a clustered and highly available system from day one; Redis, for example, has not. Hazelcast scalability is a matter of adding another process to the cluster, there is no operational downtime or manual intervention (re-sharding) required. Also, consider Hazelcast when you require improved latency. Don’t take our word for it, run your own benchmarks against Redis or MongoDB and find out for yourself. Also, when running the benchmarks definitely consider using features such as Hazelcast Near Cache.

Hazelcast understands and can query JSON documents making it a great replacement for MongoDB. Finally, Hazelcast can be embedded within your own Java applications as a cluster or as a client; something that NoSQL solutions such as Redis or MongoDB would definitely struggle with.

Hazelcast IMDG can run Java code within the cluster in the form of Callables or Runnable. These programs can be directed to the member of the cluster holding a certain key, or they can move their own processing data with them, as a true function. Because the processing can be split by key it allows all members of the cluster to actively work on jobs in parallel. As well as IMDG consider Hazelcast Jet for more advanced batch processing features in addition to its first-class support for stream processing.

One powerful capability offered by Hazelcast is the broadcast messaging system. This is inspired by JMS topics and offers a lighter weight alternative, publish events on a bus that can deliver to an arbitrary number of listeners. Hazelcast Topics is not a full JMS provider, but it is in use delivering millions of messages scalably at organizations like Ericsson and NTT of Japan.

Applications can publish a message onto a topic that will be distributed to all instances of the application that have subscribed to that topic. One of the primary benefits of this style of messaging is that it can reliably be scaled to many nodes, thus increasing the throughput of messages. Hazelcast lacks any single point of failure which is not easy to achieve with pure JMS solutions.

Hazelcast provides a distribution mechanism for publishing messages that are delivered to multiple subscribers which are also known as the publish/subscribe (pub/sub) messaging model. Publish and subscriptions are cluster-wide.