Hazelcast

Hazelcast lets applications keep and share data across a group of servers, often as an in-memory layer in front of a database. It is useful for workloads that need distributed caching or coordinated access to shared application data. The platform also includes processing capabilities formerly shipped as Jet. Before deployment, decide whether the stored data can be rebuilt from another source or is itself authoritative, because those roles need different recovery plans.

Deployment and operating notes

Hazelcast’s current Kubernetes documentation describes a vendor Helm chart for Hazelcast and Management Center, including Kubernetes API discovery and DNS-based discovery options. The platform now incorporates capabilities previously distributed as Jet. Check the edition and release-specific support matrix rather than relying on the historical IMDG popularity claims or Kubernetes minimum.

Inventory map configuration, backup counts, serialization formats, client versions, discovery settings and any persistence or external-store integration. Decide whether the data is disposable cache state or authoritative application state; the recovery plan differs substantially. Test client reconnects, member loss, rolling changes and split-brain recovery behavior under the documented topology. Preserve persisted state and a tested backup if it is required for recovery. Compare Management Center compatibility and authentication separately from member deployment. Avoid changing discovery selectors in a way that accidentally creates a second cluster with the same intended workload. A successful Helm upgrade does not prove that application objects remain readable across a serialization or major-version change.