Track two quantities instead of one, so sellable stock reflects what's actually still purchasable.
Trade-off: every inventory-touching operation has to update the right quantity, not just "the" quantity.Engineering note · 04 Commerce & reliability
Designing commerce workflows
that survive retries and race conditions.
How AP Enterprises' inventory and order systems used reservation and idempotency to stay consistent, even when requests repeat or arrive at the same time.
Topic
Commerce & reliability · Inventory reservation, idempotency
Grounded in
The AP Enterprises platform build
The problem 01
A cart isn't a guarantee, and a retry isn't a new order.
A commerce platform has to coordinate state across products, inventory, payments, deliveries, and customer history—and every one of those can be touched by more than one process at once. Two customers can try to buy the last unit of a product. A flaky network can cause a client to submit the same checkout request twice. Neither of these is an edge case; they're normal behavior under real traffic.
Building AP Enterprises meant treating inventory accuracy and duplicate-safe operations as first-class requirements of the data model and API design, not something patched in after launch.
The mechanisms 02
Order request→Idempotency check→Inventory reservation→Confirmed order
Separate "available" from "reserved," and make retries safe.
Inventory tracks available and reserved quantities separately, so sellable stock is always available minus reserved—not a single number decremented on purchase. Reserving stock at checkout, rather than only at final confirmation, prevents two customers from both believing they've secured the last unit.
Order-creating requests carry an idempotency key. Each request is matched against a stored request hash and response, so a retried request returns the original result instead of creating a duplicate operation. Inventory transactions—purchases, sales, returns, adjustments, damaged stock—are recorded individually, giving an operational history rather than just a current-quantity counter.
PostgreSQLIdempotency keysInventory reservationTransaction historyGo backend
Key decisions 03
Hold stock as soon as a customer commits to a purchase, rather than only decrementing inventory once payment finishes.
Trade-off: reserved stock has to be released correctly if a checkout is abandoned or fails.Store a request hash and its response so a retried request returns the original result instead of creating a second order.
Trade-off: requires clients to generate and persist a key, and the server to store and expire them correctly.Log every purchase, sale, return, adjustment, and damage event individually instead of only storing a running total.
Trade-off: more writes and more schema to maintain than a single quantity column.What changed 04
Transactional operations that hold up under retries and contention.
- Sellable quantity always reflects available minus reserved stock, not a single mutable counter
- Duplicate checkout requests return the original result instead of creating a second order
- Every inventory movement recorded as an auditable transaction, not just a current total
- Reviews restricted to verified, delivered purchases, enforced at the database level
- Account deletion handled through soft deletion and anonymization, preserving required order history
Lessons 05
Two customers wanting the last unit is normal traffic, not an edge case.
A network retry should never look like a new order.
"Available" and "total" are different numbers—model them separately.
An audit trail of transactions beats a single quantity field.
Reliability constraints belong in the schema, not just the application code.
Building a system that has to stay consistent? 06
Let's design for
retries and race conditions.
If a workflow needs to stay correct under concurrent requests and retries—not just the happy path—I'd be glad to talk through the data model and API design.
Start a conversation ↗