Event-driven backend / Engineering notes
OrderFlow
I built an order-processing backend that accepts work while Kafka is unavailable, then recovers without deducting stock twice in the verified local scenario.
Inspect the repositoryReviewed 6 October 2026 · 17 local tests passed · Latest measurement records remain unpublished
Interactive architecture
Follow an order through the system.
STEP 01 / 04
Accept an order
The Spring Boot API accepts the order request. This is the entry point to the asynchronous processing flow.
Keep the request path separate from inventory processing.
Select a step to inspect the decision.
The problem
Accepting an order and updating inventory cross database and broker boundaries. I wanted to understand what happens when Kafka stops, delivery repeats, or cancellation competes with processing.
My contribution
I built the Spring Boot API, order and inventory workflow, persistence, messaging, caching, React dashboard, and integration tests. Recent reliability work propagates listener failures for retry and exercises duplicate delivery, cancellation races, transaction rollback, and outbox replay.
One decision: persist before publishing
The API writes the order and its outbox event together in PostgreSQL. Publication is separate, so broker unavailability does not require losing the accepted order. Delivery remains at least once: an order-state guard and consistent order-before-product locking prevent repeated stock deduction for this transition.
What happened when Kafka stopped
In the 6 October local experiment, three orders submitted while Kafka was paused remained PLACED, their outbox rows stayed PENDING, and stock stayed at 27. After Kafka resumed, all three orders were observed CONFIRMED and their events PUBLISHED; stock became 24. Explicitly replaying one order left stock at 24. This was one controlled local scenario, not a production availability guarantee.
Verification and evidence scope
Existing XML reports and a fresh Maven build record show 17 local tests, with zero failures, errors, or skips: four unit tests and thirteen container-backed integration tests. Seven reliability tests cover duplicates, both cancellation-race winners, rollback/retry, and outbox replay. A separate baseline used 20 sequential orders at concurrency one. Neither that small sample nor the test count establishes throughput or production tail latency. The linked published engineering record describes the earlier 17-test run; the latest 6 October measurement artifacts remain local and unpublished.
Demo
Run Docker Compose from the repository, then execute ./scripts/demo.ps1 in PowerShell. The script checks order confirmation, replay with unchanged stock, cancellation conflict, and insufficient-stock cancellation. It consumes two units per run and does not reset the database. The published repository includes setup and demo instructions. This portfolio walkthrough is an architecture explanation, not a live connection to that backend.
Limits and next work
The outbox assumes one publisher. Permanent listener failures can block a partition; durable dead-letter recovery and authentication are absent. Cache eviction is not atomic with the database commit. Process-crash recovery, multi-instance coordination, and measured load behavior need separate verification.