Capstone — A Resilient Microservices System
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.
Learning objectives
- Beginner: Point to which module in this category is responsible for each piece of a real distributed request's journey.
- Intermediate: Trace what happens when one downstream service in a multi-service call chain starts failing, end to end.
- Advanced: Decide, for a new distributed feature, which of this category's patterns actually apply versus which would be over-engineering.
A single "place an order" request now touches: Spring Cloud Gateway (routing + auth, at the edge) → Config Server (every service's runtime configuration) → Eureka (resolving inventory-service and payment-service's current addresses) → OpenFeign/WebClient (making those calls) → Resilience4j's Circuit Breaker/Retry/Bulkhead (protecting against a slow or failing dependency) → distributed tracing (making the whole journey visible as one trace) → a Saga (coordinating the multi-step, multi-database business operation with compensating actions if it fails partway).
Every single piece of that sentence is one module in this category — none of it is new mechanics at this point, just composition.
payment-service becomes slow. Here's what a properly hardened system does, module by module: Resilience4j's Circuit Breaker trips after enough recent failures, failing fast instead of piling up waiting threads. The Bulkhead ensures only PAYMENT-related threads are affected, not the whole application's capacity. The Saga's compensating transaction for the ORDER and INVENTORY steps fires, since payment never completed. Distributed tracing shows exactly which service and which span was slow, the moment someone looks. None of these pieces know about each other directly — each one does its own job, and the system as a whole degrades gracefully instead of cascading into a full outage.
▲ Pitfall
Every pattern in this category solves a real problem — but applying all of them to a simple internal tool used by three people, calling one other internal service, is pure over-engineering: the operational cost (running a Config Server, a Eureka instance, tuning circuit breaker thresholds) needs to be weighed against the actual failure modes a SMALL, low-stakes system will realistically encounter. Sagas and Event Sourcing especially carry real ongoing complexity cost — reach for them when eventual consistency and compensating logic are genuinely necessary, not by default.
✓ Quick recap
- This category's patterns compose — a single real request touches most of them at once, each doing one specific job.
- A properly hardened system degrades gracefully (circuit breaks, compensates, isolates) rather than cascading into full failure when one dependency struggles.
- Every pattern here has a real operational cost — apply them where the failure modes and scale genuinely justify it, not reflexively on every service.
Want a visual for this concept?
Generate a diagram tailored to “Capstone — A Resilient Microservices System” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →