Distributed Order Processing
A microservices back end where an Order service and an Inventory service each own their PostgreSQL data and talk over REST — so an order is only placed when stock can actually be reserved. PostgreSQL makes every stock decision, so concurrent orders never oversell. Stock reads are cached in Redis, and the whole stack runs from one Docker Compose file and is tested in GitHub Actions and with k6 load and chaos tests.
RestClient — check stock, then reserve it@Cacheable — stock reads cached for 60s, evicted the moment stock is reduced61cc695Make orders safe under stress: reservations, compensation, idempotency568f686Add API demo kit, k6 load tests, and testing reportc26efb6Protect stock reductions and prepare verified demo deploymentMeasured, not assumed.
Every number below comes from a run I did myself, on an 8 GB laptop with Docker Desktop, on 10–13 Oct 2026. These are short local checks, not production capacity numbers. The runs that failed are listed too, along with what I changed because of them.
Stock stayed exact in every run: 0 lost units and 0 duplicate orders through overload and a database outage. PostgreSQL decides each sale, so a stale cache can never cause an oversell.
Freezing the database for 8 seconds lost 135 units: Inventory finished reductions after Order had given up. Now each order carries a reservation ID, Order gives stock back exactly once and answers 503 “retry” quickly, and an Idempotency‑Key stops duplicate orders.
Making that give‑back survive a crash (a reconciliation job or outbox), running several service replicas behind a load balancer, and re‑measuring on a dedicated machine.