Spring Cloud

A single Spring Boot service is easy to reason about. Ten of them, calling each other over an unreliable network, are not — this module is exactly what changes, and why an entire ecosystem of tools exists just to manage that change.

Ten services each with their own application.properties means changing one shared value ten separate times. This module is the single source of truth that replaces that.

A service instance's IP address changes every time Kubernetes reschedules it. This module is how one service finds another without ever hardcoding where it lives.

Calling another service shouldn't need the same boilerplate every single time. This module is how OpenFeign turns a service-to-service call into one annotated Java interface.

OpenFeign is declarative and simple; WebClient is lower-level and non-blocking. This module is when the second one is actually the right tool.

Spring Boot Mastery's API Gateway module covered the concept. This module is Spring's own purpose-built implementation of it, and what it adds beyond a plain reverse proxy.

A slow, failing downstream service doesn't just fail its own calls — it can quietly take the caller down with it. This module is the pattern that stops that from spreading.

Circuit Breaker is Resilience4j's headline pattern, but three quieter ones next to it matter just as much in a real production system. This module is those three.

One request that touches five services produces five separate sets of logs, on five separate machines. This module is how to make that feel like ONE trace again.

Spring Boot Mastery's @Transactional works because one database can guarantee atomicity by itself. Once a business operation spans multiple SERVICES, each with its own database, that guarantee quietly disappears — this module is why, precisely.

If 2PC doesn't survive real production microservices, what actually does? This module is the pattern nearly every real distributed system uses instead.

One model for both reading and writing data works fine until reads and writes want completely different shapes, or completely different scale. This module is what happens when you finally split them.

Most systems store the current state and throw away how it got there. This module is what changes when you store the HISTORY instead, and derive current state from it.

Retry (from two modules back) quietly assumed something this module finally makes explicit: that calling an operation twice is safe. This module is what makes that actually true.

Every module in this category hardened or connected one piece. Here's how Config Server, Eureka, Gateway, Resilience4j, tracing, and Sagas assemble into one system that survives real failure.

Database-per-service quietly broke the one thing a relational JOIN used to give you for free. This module is the pattern that stitches results back together at the API layer — and exactly where that pattern stops being enough.

CQRS and Event Sourcing are patterns you could hand-build from scratch — and the earlier modules in this category deliberately showed the raw mechanics that way. Axon Framework is the Spring-native library that gives you command/event/query buses, an event store, and the annotations to wire it all up without reinventing that plumbing yourself.

Axon's @AggregateIdentifier and @CommandHandler only make sense once you understand what they're annotating a boundary around. This module is the Domain-Driven Design concept underneath them: the aggregate as the single unit of consistency every command must go through.

The Aggregate pattern put business-invariant checks inside the aggregate itself — but a command's basic shape, authorization, and audit trail shouldn't have to be re-coded inside every single aggregate. This module is where that cross-cutting work actually belongs.

Every @EventHandler in a projector has to actually be invoked by something as events flow past — Axon calls that something an event processor, and it comes in two fundamentally different modes with very different operational consequences.

CQRS's query side has been described conceptually in earlier modules — this is where it actually gets built: a denormalized table, kept continuously current by a projector, purpose-shaped for exactly the query the UI needs.

Tracking processors were introduced specifically because they make replay possible — this module is replay itself, and its natural companion: subscription queries, which push live updates to a UI as new events land instead of making it poll.

The Aggregate pattern's one-stream rule means loading an aggregate replays its ENTIRE history, every single time — fine for dozens of events, a real cost for thousands. Snapshotting is the fix, and knowing exactly what it trades away is the point of this module.

The original 12-Factor App methodology was written for the PaaS era. Running on Kubernetes surfaces three gaps the original list never had to cover — telemetry, authentication/authorization, and API-first design — and this module covers what each one actually demands of a service.

Kafka isn't the only message broker worth knowing. RabbitMQ's AMQP model — exchanges, queues, bindings, routing keys — solves a different shape of problem, and this module covers that model plus when reaching for RabbitMQ over Kafka is the better engineering call.

Deploying a Spring Boot service to Kubernetes means hand-writing a Deployment, a Service, and a ConfigMap for every environment. Helm turns that into a versioned, parameterized package — a chart — and this module covers charts, templating, releases, and rollbacks.

Kubernetes solves service discovery differently from Eureka — through ClusterIP Services, cluster DNS, and kube-proxy rather than a client-side registry. This module covers that native mechanism and contrasts it with the Eureka-based approach already covered for non-Kubernetes environments.

Resilience4j protects a service from a failure it already knows about, at the application layer. A service mesh moves traffic management and security entirely out of application code — this module covers the sidecar proxy pattern, Istio's VirtualService and DestinationRule, and mutual TLS for zero-trust service-to-service security.

A fleet of microservices that each pin their own dependency versions will drift apart one upgrade at a time. A shared Bill of Materials (BOM) module centralizes version decisions in one place every service inherits from, and this module covers building and consuming one.