Why one order needs three consistency rules

01 / Make correctness concrete

After a checkout timeout, a customer cannot tell whether the server committed the order. Retrying may reserve stock twice, while two customers may compete for the last item. These are separate problems: one requires recognizing the same intent; the other requires protecting shared stock. Disabling repeated clicks only improves the interaction.

• Retrying the same intent creates one order and one stock reservation.
• Stock cannot become negative, and invalid state transitions must be rejected.

02 / Bind an idempotency key to its content

The existing review records that createOrder looks up an order by college, user and requestId, then compares a digest of normalized business content. The same key and content return the existing order; changing the quantity under that key is rejected. The key therefore represents an agreement about intent, rather than merely a cache lookup.

Teaching sequence (synthetic identifiers)
A: requestId=r-01, items=[{productId:7, quantity:1}]
A retry: same key + same content -> existing order
A changed: same key + quantity:2 -> reject conflict
B: another user + r-01 -> a separate scoped request

This is a behavior sketch, not a directly callable API payload. A retry should preserve the original key; a new purchase intent needs a new key.

03 / A transaction protects a set of business facts

The source-review note describes a READ_COMMITTED transaction, product locks acquired in ascending ID order, and a second existing-request check after locking. A waiting request may become a duplicate while another transaction finishes, so the first check is insufficient. Database prices and BigDecimal determine totals; the order snapshot, stock reservation and creation event commit together.

Consistent lock ordering reduces lock-order inversions, but popular products still cause waiting. This does not establish freedom from deadlocks or high throughput; timeouts, rollback and retry policies require separate measurement.

04 / Idempotency and state machines do different jobs

Tasks progress through QUEUED → INSPECTING → LOCATING → PICKING → COMPLETED. An eventId identifies repeated receipts, while state rules prevent skipped stages. An explicit retry returns a failed task to the queue. Both checks matter: a new event may be invalid, and a duplicate event must not advance the task again.

Cancellation also checks the current order state; cancelling an already cancelled order must not release stock again. Dispatch and receipt remain distinct, and a successful simulated payment does not establish a real transfer of funds.

05 / Test rules with counterexamples

Useful tests assert final order counts, stock and event counts, rather than only successful responses. A proposed review would use an isolated database, fixed initial stock and synchronized competing requests, then check for partial orders after failure. The cases below are a verification plan, not results from this update.

• Concurrent identical retries: one order and one reservation. Changed content under the same key: reject.
• Two buyers for the last item: at most one succeeds. Repeated cancellation: release stock once.
• Skipped QC, out-of-order receipts and replays: reject invalid advancement or return the existing result.

06 / Keep conclusions within the evidence

The historical inventory records 41 passing backend tests, including nine order-workflow tests; none were rerun for this note. The raw reports are not public, so their hashes support later comparison rather than independent reproduction. Useful next steps are a minimal isolated environment, failure injection and lock-wait records before evaluating multiple nodes or external payments.

The project reuses an existing college application and vue-next-admin. This note extracts decisions from the business adaptation without claiming personal authorship of the reused framework or production validation of the simulation.