Event-Driven Microservices with Hazelcast: Series Index

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.

  1. Event-Driven Microservices: Avoiding Distributed Monoliths — 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.

  2. Hazelcast Microservices Framework: Event Sourcing Demo — 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.

  3. Launching a Claude Code Project: Design Before You 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.

The Series

The numbered parts walk through the framework’s architecture one component at a time. Interludes — the shorter, reflective detours — are slotted in at the point in the sequence where they belong rather than collected off to the side.

  • Interlude — How 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 before the technical parts begin. Read →
  1. Part 1 — Event Sourcing on 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.

  2. Part 2 — Hazelcast Jet Event Pipelines: A Six-Stage Walkthrough — 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.

  3. Part 3 — Hazelcast Materialized Views: CQRS for Sub-ms Reads — 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.

    • Interlude — A Note on Observability — why the observability post got pushed back to later in the series, and why that didn’t change anything about when to instrument the code. Instrument early; you’ll thank yourself at 2 AM on phase 3. Read →

  4. Part 4 — Saga Pattern: Distributed Transactions Without 2PC — When a business operation spans four services, a single database transaction can’t span them — and two-phase commit’s distributed locks are worse than the problem they solve. Part 4 walks through the saga pattern: a sequence of local transactions coordinated through events, compensation when steps fail, a saga state machine in Hazelcast, and timeout detection for stuck flows.

    • Interlude — On Debugging by Assumption — the saga timeouts I blamed on a maxed-out laptop turned out to be four real bugs, starting with a circuit breaker that tripped on ordinary out-of-stock errors. Measure before you assume. Read →

  5. Part 5 — Vector Similarity Search on Hazelcast with HNSW — Full-text search matches keywords, so “portable computer for games” never finds the gaming laptop sitting in your catalog. Part 5 adds semantic “more like this” search: a local all-MiniLM embedding model (no API key), Hazelcast’s VectorCollection holding the vectors, and HNSW indexing that turns an O(n) scan into an O(log n) lookup — with a brute-force fallback that keeps it fully working on Community Edition.

    • Interlude — On the Vector Store I Didn’t Ask For — I asked Claude for Hazelcast’s VectorCollection and got a from-scratch brute-force store instead. It worked well enough to become the Community Edition fallback — a small parable about AI and enterprise software. Read →

  6. Part 6 — MCP Server for Microservices: AI-Powered Debugging — Five posts of infrastructure later, investigating a failed saga still meant chaining five or six curl commands by hand. Part 6 adds an MCP server — a thin REST proxy with no Hazelcast dependency, exposing ten tools — so an AI assistant can query the views, submit events, inspect sagas, run demo scenarios, and replay failures off the dead-letter queue. The five-command debugging session collapses into a single sentence.

Coming Up

The series continues with posts on 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.