Capstone — A Production-Ready System
Every module built or hardened one piece. Here's the whole system, fully assembled — an Order → Kafka → Inventory/Notification/Analytics architecture, secured, cached, gatewayed, and containerized.
Learning objectives
- Beginner: Point to which module covered each piece of the finished system (auth, persistence, caching, messaging, containerization).
- Intermediate: Decompose a new feature request into the same shape this system uses — a DTO, a JPA relationship, an authorization rule, an event.
- Advanced: Extend the capstone system with a genuinely new capability (e.g. a new consumer service) without breaking its existing contracts.
The full capstone: a gateway-fronted, JWT-secured, Redis-cached Order Service persisting to Postgres, publishing events to Kafka that Inventory, Notification, and Analytics services each consume independently — all orchestrated by one docker-compose file.
| Capability | Modules |
|---|---|
| Explain what the IoC container and dependency injection are actually doing, and why constructor injection is preferred | 02, 03, 04 |
| Build a REST API with correct DTOs, never leaking a JPA entity directly | 06, 07 |
| Design JPA relationships correctly and diagnose an N+1 query problem | 08, 09 |
| Handle errors and validation centrally, with a consistent error contract across the whole API | 10, 16 |
| Secure an API statelessly with JWT, including choosing HS256 vs. RS256 deliberately | 12, 13 |
| Enforce fine-grained authorization beyond simple roles, including ownership checks | 14 |
| Design a refresh-token flow that balances security and user experience | 15 |
| Cache correctly — cache-aside, TTLs, and matching invalidation on every write path | 17 |
| Decide when microservices are actually justified, and where to draw service boundaries | 18 |
| Design event-driven, decoupled services with Kafka, accounting for at-least-once delivery | 19 |
| Front a multi-service system with a gateway and design for downstream failure with a circuit breaker | 20 |
| Orchestrate an entire multi-container system with Docker Compose | 21 |
◆ Beyond what's covered here
Suggested extensions past what's covered here: Service discovery & dynamic scaling — replace the gateway's hardcoded routes (Module 20) with a service registry (e.g. Eureka) so services register themselves dynamically instead of the gateway needing a fixed, manually-maintained address list. Distributed tracing — add OpenTelemetry so a single order-placement request can be traced end to end across the gateway, Order service, Kafka, and every downstream consumer, correlated by one trace ID. Saga pattern — for an operation that must coordinate state across multiple services (e.g. "reserve inventory AND charge payment, or roll both back"), explore the saga pattern as the event-driven alternative to a traditional distributed transaction. Kubernetes — take the docker-compose stack from Module 21 and re-express it as Kubernetes Deployments and Services for a real multi-node, self-healing deployment target.
✓ Final check
If you can look at a real feature request — "let a customer place an order, get notified when it ships, and let support staff (but not regular customers) view any customer's order history" — and immediately decompose it into a DTO shape, a JPA relationship, an authorization rule, and an event a downstream service reacts to, rather than reaching for one giant controller method, this site has done its job. Go build something.
Want a visual for this concept?
Generate a diagram tailored to “Capstone — A Production-Ready System” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →