What is our primary use case?
My main use case for Hazelcast Platform is to build distributed cache systems across different services that we have. The biggest use is the caching. Additionally, from time to time, we use this for streaming and stream processing.
We use Hazelcast Platform to store user session states or session data, making it accessible across multiple application servers, allowing applications to scale horizontally. This is mostly clustering. We also use it for near-cache scenarios where we have to store frequently used data in the client application to reduce network latency.
What is most valuable?
I think the top core features of Hazelcast Platform for us are in-memory data storage, particularly the speed, because it can store data off-heap to eliminate long garbage collection pauses. The high-performance stream processing is also a significant feature. The processing engine runs directly where the data partitions live, eliminating network hops, which is very useful for us.
For our JVM-based services and applications, the in-memory data storage and stream processing features of Hazelcast Platform have made a difference for our team because we periodically used to pause the service to clean up deleted data, which would take seconds and crash the real-time processing and application. Hazelcast Platform bypassed this and stored the data directly in the server's off-heap native memory. Without this storage, we saw three-second garbage collection pauses, but now it is under two milliseconds. This is definitely an improvement. Another aspect is tiered storage; during peak seasons such as Black Friday, our systems have a lot of inventory updates. Hazelcast Platform retrieves it from the SSD without taking up memory space, which is extremely useful. In terms of stream processing, we used to have a server with the log, and another server was pulling the log from the network to analyze. Hazelcast Platform does all the analytics work inside the first server where the data is sitting, which eliminates all network overhead and enables real-time performance.
There have definitely been a lot more latency reductions and better SLA performance since using Hazelcast Platform, resulting in faster time to market overall for new features and capabilities because the architecture has become simpler. Developers can now focus on business logic rather than writing complex integration code due to this simplicity, and the time to market for delivery has increased.
Regarding improved SLAs or faster time to market with Hazelcast Platform, we had services that were handling about 25 million daily transactions. After implementing Hazelcast Platform, we were able to meet those SLA targets more consistently. It took time to migrate to Hazelcast Platform, but overall the SLAs were met and proved to be better than usual.
What needs improvement?
I think there are areas where Hazelcast Platform can improve, such as simplifying the cluster topology and sizing rules because they are still somewhat complex for someone new to Hazelcast. Understanding how the cluster topology forms and sizing rules work, such as partition balancing and traffic routing, should be much simpler. If one node has less RAM or a slightly slower CPU, it creates a cluster-wide performance bottleneck, which is critical, especially with transactional systems. Even though Hazelcast Platform has proven to be better, there can still be bottlenecks if the cluster topology and data partitioning are not easily understood. I also think that object handling and streamlined serialization should be prioritized; using standard Java serialization can be extremely slow. Providing native ultra-fast binary serialization out of the box, without requiring developers to write custom adapters, would be a significant improvement. It would be great if there were ready-to-use adapters for streamlined serialization and object handling.
For how long have I used the solution?
I have been using Hazelcast Platform for the past three years.
What do I think about the stability of the solution?
Hazelcast Platform is mostly stable.
What do I think about the scalability of the solution?
The scalability of Hazelcast Platform is decent.
How are customer service and support?
The customer support for Hazelcast Platform is good, with a lot of quality support available.
Which solution did I use previously and why did I switch?
We used traditional databases before switching to Hazelcast Platform. We encountered many problems with them, and Oracle Coherence was a key solution we used that had a high licensing cost and complex legacy management overhead. It is drastically easier to switch to Hazelcast Platform for deployment, especially on the Kubernetes side with its cloud-native architecture. The performance requirements are better compared to Oracle Coherence. We also had some Redis-based systems, but because of the multi-threaded nature of Hazelcast Platform, we switched some of those systems from Redis to Hazelcast Platform.
Which other solutions did I evaluate?
Before choosing Hazelcast Platform, we evaluated Redis and Oracle Coherence as two other major options where we already had some existing presence.
What other advice do I have?
My advice for others looking into using Hazelcast Platform is to study the architecture and data modeling thoroughly. Choosing the right topology for the application or platform is crucial when using Hazelcast Platform because it decouples your application lifecycle from Hazelcast Platform data cluster, allowing for updates to microservices without risking data loss. It is very important to consider the cluster sizes, serialization designs, and the system's availability and resiliency regarding metrics and eviction policies, such as time to live or max idle parameters when starting with Hazelcast Platform. I would rate this product an 8 out of 10.
Which deployment model are you using for this solution?
On-premises
