Hazelcast Trainer

The problem before the product. Where a cache, a data grid and a database each belong, what embedded versus client-server topology actually changes for latency and operations, and an evidence-based comparison against Redis, Memcached, Apache Ignite and Coherence.

Topics: Caching, data grid and database — the real distinctions · Hazelcast architecture: members, clients, partitions · Embedded topology versus client-server topology · Hazelcast compared with Redis, Memcached, Ignite and Coherence · Open source edition versus enterprise features · First cluster: forming, joining and observing members

• Assignments: (1) Form a three-member cluster and observe partition ownership as members join; (2) Compare embedded and client-server latency for the same operation
• Capstone: Write an architecture note choosing a topology and justifying Hazelcast over the alternatives for a specific workload

The mechanics that everything else depends on. How members discover each other in each environment, how keys map to partitions, how primary and backup copies are placed, and exactly what happens to ownership, in-flight operations and data when a member joins or dies.

Topics: Discovery: multicast, TCP/IP, Kubernetes, AWS, Azure and GCP plugins · The partition table, partition count and key-to-partition mapping · Primary and backup copies, backup-count and async-backup-count · Partition migration and rebalancing on member change · Member lifecycle, graceful shutdown and safe member removal · Partition groups and rack or zone awareness · Cluster state: ACTIVE, FROZEN, PASSIVE and NO_MIGRATION · What a client sees during a migration

• Assignments: (1) Kill a member under load and measure the impact on reads and writes; (2) Configure partition groups so backups never land in the same availability zone
• Capstone: Design a cluster layout that survives the loss of a whole availability zone with no data loss

The API surface, and the judgement about which structure fits which job. Partitioned versus replicated collections, queues and topics for messaging patterns, ringbuffers for replayable streams, and the identifier generators that avoid a database sequence.

Topics: IMap: the partitioned map and its guarantees · ReplicatedMap and when full replication beats partitioning · MultiMap and ISet, IList · IQueue and the caveats of a distributed queue · ITopic and ReliableTopic for publish/subscribe · Ringbuffer for bounded replayable streams · FlakeIdGenerator, PN counters and CardinalityEstimator · Choosing the right structure and the cost of choosing wrong

• Assignments: (1) Rebuild a workflow using three different structures and compare throughput and semantics; (2) Replace a database sequence with FlakeIdGenerator and verify uniqueness under concurrency
• Capstone: Model an application's shared state entirely in Hazelcast structures, with the choice for each justified

Where most production time is spent. Eviction policies and size limits, TTL and max-idle expiry, indexes and how they change predicate cost, SQL over the grid, near cache and its invalidation behaviour, and entry processors that move computation to the data instead of the data to the computation.

Topics: Eviction policies, max-size policies and per-map configuration · TTL, max-idle and expiry semantics · Sorted, hash and bitmap indexes · Predicates, Predicate API and the SQL engine · Aggregations and projections · Near cache: configuration, invalidation and staleness · Entry processors and executing code on the owning member · Entry listeners, continuous queries and map events · In-memory format: BINARY, OBJECT and NATIVE

• Assignments: (1) Add an index and measure the change in query time on a million entries; (2) Replace a read-modify-write loop with an entry processor and compare network traffic
• Capstone: Tune a heavily queried IMap so a defined workload meets a stated latency budget, with before-and-after measurements

The most common cause of disappointing benchmarks. How Hazelcast serialises objects, why default Java serialization is expensive, and how IdentifiedDataSerializable, Portable and Compact serialization change CPU cost, payload size and schema evolution — measured rather than asserted.

Topics: How and when Hazelcast serialises · Java Serializable and Externalizable, and their real cost · DataSerializable and IdentifiedDataSerializable · Portable serialization and partial deserialization for queries · Compact serialization and schema evolution · Custom serializers and global serializers · Payload size, CPU cost and the effect on throughput · Benchmarking serialization honestly

• Assignments: (1) Benchmark the same object across four serialization strategies and record the results; (2) Evolve a schema without breaking a running cluster
• Capstone: Choose and implement a serialization strategy for a real domain model, with measurements defending the choice

Connecting the grid to the system of record. MapStore and MapLoader for read-through, write-through and write-behind, the failure semantics of each, and the integrations most JVM estates actually need — JCache, Spring, Hibernate second-level cache and HTTP session replication.

Topics: MapStore and MapLoader interfaces · Read-through, write-through and write-behind · Write-behind coalescing, batching and what is lost on failure · Warming a map at startup with loadAllKeys · JCache and the JSR-107 API · Spring and Spring Boot integration · Hibernate second-level cache · Web session replication for Tomcat and Jetty · Cache invalidation strategies against a changing database

• Assignments: (1) Implement a MapStore with write-behind and prove which writes survive a member kill; (2) Put a Hazelcast second-level cache in front of a JPA workload and measure the database load reduction
• Capstone: Build a cache-aside and write-behind layer over a relational database with a documented consistency and recovery story

The module that separates a demo from a production design. Hazelcast's default AP behaviour and what it means for correctness, how a network partition produces split brain, how merge policies resolve it, and when to use the Raft-backed CP subsystem instead of hoping.

Topics: AP behaviour by default and its practical consequences · Network partitions and how split brain forms · Split-brain protection: minimum cluster size and protection functions · Merge policies and writing a custom one · The CP subsystem and Raft group membership · FencedLock, IAtomicLong, IAtomicReference, ISemaphore, ICountDownLatch · Why an AP lock is not a lock, and the fencing token argument · CP session behaviour, failure and recovery

• Assignments: (1) Induce a split brain in the lab, then observe and control the merge; (2) Replace an unsafe distributed lock with a FencedLock and demonstrate the difference
• Capstone: Produce a consistency design for a workload with a mixture of AP-tolerant and strictly-consistent operations

The stream processing engine, then everything required to keep a cluster healthy. Jet pipelines, sources and sinks, windowing and fault-tolerant snapshots — followed by Kubernetes deployment, sizing, GC behaviour, Management Center, monitoring and rolling upgrades.

Topics: Jet pipelines: sources, transforms, sinks · Stateful transforms, windowing and event time · Snapshots, exactly-once processing and job restart · Connecting Jet to Kafka, JDBC and IMap · Deploying on Kubernetes: operator, StatefulSet, discovery, readiness · Heap sizing, native memory and GC tuning under load · Management Center: metrics, alerts and cluster operations · Monitoring with Prometheus and Grafana · Rolling upgrades, backups and disaster recovery · Security: TLS, mutual authentication and client permissions

• Assignments: (1) Build a Jet pipeline from Kafka into an IMap with a tumbling window and restart it from a snapshot; (2) Perform a rolling upgrade of a live cluster with no failed client operations
• Capstone: Deliver a production-ready cluster on Kubernetes with sizing, monitoring, security and a rehearsed upgrade procedure