This is a running index of the Building Event-Driven Microservices with Hazelcast series — a multi-part walkthrough of an event-sourced microservices framework built on top of Hazelcast. The series goes through the architectural patterns piece by piece: event sourcing as the source of truth, CQRS and materialized views for fast queries, Hazelcast Jet pipelines for processing, saga patterns for distributed transactions, resilience patterns for production, and observability for everything in between.
The framework itself is a working demo — not a toy, not a slideware reference — that I started years ago at Hazelcast and have been extending recently with the help of Claude Code. Every post in the series ties back to actual running code in the hazelcast-microservices-framework repository on GitHub. If you’d rather read the code first and the prose second, that’s a fine way to do it.
If you’re new here and not sure where to start: read the Foundation posts in order if you want the why before the how, or skip directly to The Series if you’d rather start with code.
Foundation
These three posts set up the context for the rest of the series — why event-driven matters, what the framework is, and how it got built.
- Why Event-Driven Microservices? — Why teams who set out to build microservices keep ending up with distributed monoliths, and what an event-driven architecture buys you that synchronous service-to-service calls can’t.
-
The Hazelcast Microservices Framework — Introduction to the demo project: a working framework that implements the common microservices patterns on top of Hazelcast, with all the integration points you’d actually need in production.
-
Launching a Claude Code Project: Design First, Then Build — A meta post on the development process: how I went from a vague idea to nine design documents and an implementation plan before writing a single line of code, using Claude’s desktop interface for design and Claude Code for implementation.
Interlude
- Baseball Invented Event Sourcing 150 Years Ago — A short detour into why the pattern feels familiar to anyone who’s ever kept score at a ballgame. Useful framing if you’re trying to explain event sourcing to someone who isn’t a software engineer.
The Series
The numbered parts walk through the framework’s architecture one component at a time.
- Part 1 — Event Sourcing with Hazelcast: A Practical Introduction — Every UPDATE statement destroys information. Event sourcing flips the model: store the events that produced your state, not the state itself. This post walks through how Hazelcast handles the whole stack — fast event writes, Jet pipelines for processing, sub-millisecond materialized views — without bolting together five different technologies.
-
Part 2 — Building the Event Pipeline with Hazelcast Jet — A close look at the Jet pipeline that does the heavy lifting: six stages that turn an inbound event into a persisted record, an updated view, and a published notification, all in under a millisecond. Covers the partitioned-sequence-key design, the ServiceFactory pattern for distributed lambdas, and the lock-free concurrency model that makes the whole thing fast.
-
Part 3 — Materialized Views for Fast Queries — If everything is stored as a sequence of events, how do you actually query anything? Part 3 introduces CQRS and the materialized view layer — pre-computed projections built by the Jet pipeline that give sub-millisecond reads, cross-service denormalization without HTTP fan-out, and free view rebuilds from the event stream.
Coming Up
The series continues with posts on the saga pattern for distributed transactions, circuit breakers and retry for resilience, the transactional outbox pattern, dead-letter queues and idempotency, choreography vs. orchestration, durable persistence with write-behind MapStores, observability in event-sourced systems, and performance engineering. This index page will be kept up to date as new parts publish.
The Code
All of the code referenced in the series lives in github.com/myawnhc/hazelcast-microservices-framework. Clone it, run the Docker Compose stack, and the framework boots locally in a couple of minutes with sample data preloaded.