Backend Correctness · Completed study
CommerceCore
A Spring backend for testing what remains correct when inventory races, payment responses disappear, and messages are delivered more than once.
Why I built it
CommerceCore is not a storefront. I built it to make checkout failure boundaries visible: PostgreSQL can own an atomic local transaction, but it cannot make a separate payment database and Kafka part of that transaction without a different protocol.
Architecture
The CommerceCore service owns orders, reservations, idempotency records, and outbox rows in PostgreSQL. A separate gRPC Payment Service owns provider request identity and authorization results in its own database. Kafka distributes facts after local commit.
Java · Spring Boot · PostgreSQL · gRPC · Kafka · Testcontainers
The failure boundaries
Conditional inventory updates prevent overselling under contention. Checkout retries map to the same durable result. If the provider commits and the gRPC deadline expires, the payment becomes UNKNOWN rather than FAILED. Reconciliation looks up provider truth without reauthorizing. If authorization arrives after inventory expiry, the order becomes REQUIRES_REVIEW rather than inventing a safe automatic transition. Webhook receipts, outbox consumers, and Kafka handlers tolerate duplicate delivery.
What I actually tested
- concurrent inventory reservation and checkout attempts
- idempotent retries across process restart
- provider timeout after a committed authorization over real TCP gRPC
- duplicate webhook and Kafka delivery
- reconciliation conflicts and authorization after reservation expiry
Boundary and trade-off
This is a bounded correctness laboratory for one merchant and currency, not a complete commerce application. Delivery is at-least-once; the design contains duplicates rather than claiming they cannot occur.