The Problem
Fulfillment systems coordinate work across boundaries, but not every boundary should use the same communication style. Order progress and shipment creation are good event-stream work; checking available stock needs a direct answer from the inventory service.
FlowOps is built around that distinction. It uses Kafka for asynchronous fulfillment events and HTTP for targeted inventory reads, with Redis caching and circuit-breaker behavior around the inventory dependency.
What I Built
I built a four-service Spring Boot system: order, inventory, warehouse, and shipment. The order service validates requests and publishes accepted orders, the warehouse service selects the fulfillment location, the shipment service creates idempotent shipment records, and the React dashboard surfaces orders, shipments, inventory, and metrics.
Project Overview
FlowOps is an independent distributed-systems build with public source, service tests, Docker Compose, and a dashboard screenshot.
My Contribution
- Designed the four-service architecture and the hybrid transport model: Kafka for async fulfillment events, HTTP for targeted inventory checks.
- Implemented deterministic warehouse routing, Redis-backed inventory caching, Resilience4j circuit-breaker configuration, idempotent shipment processing, correlation IDs, and structured logs.
- Built the React operations dashboard, Docker Compose environment, failure-simulation workflow, and service-level test suite.
System Architecture
Hybrid fulfillment communication
Order, warehouse, inventory, and shipment services coordinate through asynchronous events and targeted HTTP reads.
Kafka is used for fulfillment events; HTTP is used when a service needs a direct stock answer.
Fulfillment dashboard
Real screenshot from the public repository's docs/screenshots/dashboard.png, running against synthetic order data.
Synthetic customer and SKU IDs only. No real retailer data is shown.
Technical Decisions
Use two communication styles instead of forcing everything through Kafka.
- Fulfillment progress can be asynchronous, but an inventory check needs a current, targeted answer.
- The architecture has more than one transport to test and explain.
- The service boundaries are more honest: event streams carry progress, while HTTP handles read-before-routing decisions.
order -> inventory: HTTP stock check
order -> kafka: order.accepted event
warehouse -> inventory: HTTP stock and deduction calls
warehouse -> kafka: route.assigned event
shipment -> database: idempotent shipment record
Routing And Resilience
Engineering Challenge
- A routing service has to make the same decision repeatedly when the same stock picture appears.
- The warehouse tests cover sufficient stock, insufficient stock, empty inventory, exact matches, and tie-breaking.
- The routing algorithm filters warehouses that can fulfill the quantity, chooses the highest stock, and applies deterministic tie-breaking.
- Routing behavior is predictable enough to test and easy to reason about in logs and dashboard views.
Engineering Challenge
- Inventory failures should not turn one unavailable dependency into a system-wide failure.
- The order service includes a simulated inventory-down flag and Resilience4j circuit-breaker configuration.
- The fallback saves the order in a pending inventory-check state, and the README documents a failure-simulation workflow.
- The system demonstrates bounded failure behavior without claiming measured uptime.
Quality & Testing
Quality Evidence
Product engineering evidence
- Source inspection found 26 service `@Test` methods: 7 order, 6 inventory, 6 warehouse, and 7 shipment tests. Local execution was blocked because Maven is not installed in this environment.
- GitHub Actions runs each service test job and then builds the four backend services.
- README and source verify Kafka topics, HTTP inventory clients, Redis cache config, Resilience4j, PostgreSQL, Docker Compose, and the dashboard boundary.
Public page quality
- The architecture visual uses text labels in addition to color and line style.
- The screenshot and SVG diagram scale inside the shared case-study layout.
- The page publishes only public repository evidence and synthetic data.
| Evidence area | Source-backed detail |
|---|---|
| Async events | order.accepted and route.assigned Kafka topics |
| Direct reads | Order and warehouse inventory HTTP calls |
| Caching | Redis-backed inventory cache configuration |
| Resilience | 5-request circuit-breaker window, 50% threshold, 10-second wait, 2 probe calls |
| Idempotency | Duplicate route events create one shipment |
Results & Impact
FlowOps demonstrates backend judgment rather than just service count. The important result is the transport choice: asynchronous where it helps decouple fulfillment progress, request-response where the domain needs an immediate stock answer.
What I Learned
Architecture communication is part of engineering correctness. When a system is hybrid, the diagram and the README have to say so plainly.