When only one unit remains, which order gets it?#

Two people place orders for a product that has one unit left, almost at the same time.

If both reach payment, both see “your order is being processed,” and only then does someone get a cancellation notice, the problem is not a wrong count of one. You trigger payment reversals, refunds, support load, seller firefighting, and lost trust.

The principle I want is simple:

Only one order should get the last unit. For everyone else, sold out beats a payment reversal.

So when stock is down to one, I do not authorize payment first. I hold inventory for a single order and show sold out to others. Then I request payment authorization. On a clear payment failure, release the hold immediately; on checkout abandonment, release only after a defined TTL.

The point is not the slogan “deduct inventory first.” Treat inventory as reserved and define who can confirm or roll back that reservation under each outcome.

Between deduction and payment authorization there is a reservation state#

If you decrement stock before taking payment, someone will ask:

When payment fails, how do you put inventory back?

The answer is reservation, not a permanent decrement. The moment you assign the last unit to an order, the state should be reserved for checkout, not sold. (These labels are illustrative—not tied to a particular product codebase.)

• Available for sale: New orders may claim a hold.
• Reserved for checkout: Only that order may complete payment; others see sold out.
• Sold: Payment is final; no further sales.
• Released: After failure, cancel, or expiry, stock returns to available for sale.

Stripe Checkout for limited inventory uses session expiry so unpaid customers do not hold stock indefinitely, and documents listening for expiry to restore reserved quantity.[1] Session TTL is not the universal answer for every payment method or custom checkout—set hold duration from time-to-pay, scarcity, and processor behavior.

UX follows the same rule: if the last unit is reserved for checkout, do not tease other customers with “almost yours.” Show sold out until the hold expires.

Claiming one order breaks if you split read and write#

The common mistake is read stock, decide in application code that stock exists, then decrement later.

1. Read current stock: 1
2. If stock > 0, create the order
3. Subtract 1 from stock

Two requests can both read 1 at step 1 and both create orders. The bug is not the payment provider—it is separating the inventory decision from the write.

Claiming the last unit must put condition and mutation in one database write, for example:

UPDATE inventory
SET available_quantity = available_quantity - 1,
    reserved_quantity = reserved_quantity + 1
WHERE product_id = :product_id
  AND available_quantity > 0
RETURNING available_quantity;

UPDATE changes only rows that satisfy WHERE; RETURNING gives back the new values.[3] No returned row means this request did not claim the last unit. Under PostgreSQL’s default Read Committed, concurrent updaters on the same row wait for the first commit, then re-evaluate WHERE against the updated row.[7]

That beats SELECT then “we still have stock, so decrement.” Multi-SKU carts, coupons, limits, and split carts may need transactions, lock ordering, or optimistic concurrency—not a single SQL generalization for every flow. Row locks block other writers until the transaction ends.[8]

Payment failure, abandonment, and timeout are not the same failure#

“Release the hold” does not mean one code path for every bad outcome.

1. Clear payment failure → recover immediately#

On an explicit decline (e.g. card rejected), release that order’s reservation at once. Release means only while that reservation is still active—not blindly adding 1 to stock.

Track reservation_id and states so RESERVED → RELEASED happens once. Duplicate failure webhooks or manual replays must not inflate inventory twice.

2. Checkout abandonment → recover via expiry#

Closing the browser does not always emit a failure event. Reservations need a server-side expiry time. After expiry, find the hold, release it, and refresh sold-out UI to available if appropriate.

Client countdowns are guidance only; the server owns expiry and state. Stripe describes restoring reserved inventory on checkout.session.expired after session expiry.[1]

3. Timeout → unknown outcome, not immediate failure#

The dangerous case: you sent a payment request and got no response. A network timeout does not mean the processor never received the request—it may have approved and the response is late. Treat external call timeouts as unknown until reconciled; without idempotency keys or inquiry APIs from the processor, you choose between duplicate charges and lost approvals.

Do not release inventory the instant a timeout fires. “Recover after the timeout window” here means:

1. Define per-processor max response and webhook delay in operations policy.
2. Until then, keep the reservation in an awaiting payment outcome state (payment may have succeeded, failed, or still be in flight—you do not know yet).
3. After the deadline, query the processor and internal records; release only if there is no success.
4. When a late success webhook collides with release, use conditional transitions so one wins.

That conservatism can briefly show false sold-out. It beats missing a successful charge or promising the last unit twice. If the processor offers no inquiry API or idempotency contract, this becomes a business risk choice, not purely engineering.

Retries must not create a new order#

Users double-tap pay; mobile networks drop responses. A repeated create-order request must return the first attempt’s outcome—not a new hold or new payment.

HTTP POST may apply state change on every call. An API can use a stable Idempotency-Key so the server treats replays as one operation—if it stores and enforces the key; support is API-specific.[4] Stripe returns the first result for the same key and errors when parameters differ under the same key.[5]

Do not treat the key as log decoration. Persist at least:

• Order or reservation ID for the key
• Processing state (processing, completed, failed)
• Fingerprint of the original input
• Stored response and retention period

In-flight duplicate keys should return “processing,” not a new order. Completed keys should replay the stored response. Idempotency is a contract to reuse the outcome of one business request, not magic in the header alone.

AWS recommends persisting idempotency tokens and related state and coordinating token records with state changes under proper concurrency control to avoid races.[6]

Do not try one DB transaction for inventory and the payment processor#

Inventory DB and an external processor cannot share one atomic transaction. You need explicit success and compensation per step, not “finish both at once.”

Available for sale
  → Create reservation / claim stock
  → Request payment
  → Payment success: confirm reservation / order complete
  → Explicit payment failure: release reservation
  → Customer leaves: release after expiry
  → Response timeout: payment pending → query/deadline → confirm or release

That sequence of local changes and compensating steps is a saga. AWS distinguishes compensating transactions for business-rule failures (roll back inventory/order state) from forward recovery (retries) for infrastructure failures.[2]

If order confirmation triggers notifications, fulfillment, or analytics events, you can still die after committing inventory but before publish. Transactional outbox (same transaction for state + outbox row, relay publishes later) is worth considering at scale—but for a small order flow, get reservation / confirm / release transitions right first.

Counterpoint: Won’t holding stock before payment hurt conversion?#

Yes, sometimes. Long holds let non-payers block scarce SKUs while others only see sold out. Short holds on scarce items can feel pressuring.

This post is not “every shop needs long holds.”

• Plenty of stock: deduct after payment may stay simpler.
• Last units, limited drops, seats/tickets: reservation often wins when oversell cost is high.
• Hold duration should follow processor limits, real pay times, and the cost of cancellations—not marketing copy alone.
• Release jobs must be idempotent so one reservation is not freed twice.

My rule:

If sold out beats a payment reversal for your customers, manage the last unit by reservation state—not by payment outcome alone.

The last unit is not “whoever’s HTTP request arrived first.” It belongs to the order that claims stock once and keeps that promise until payment outcome is clear.

Sources#

1 2 3 4 5 6 7 8

Suppose an order API looks like this:

1. Look up whether the same order already exists.
2. If not, create the order.
3. Deduct inventory.

It works fine most of the time. Then payment completes and the response drops. The user thinks the order failed and taps again. The app may retry the same request after a timeout. If two requests pass the initial lookup almost at the same time, both can decide no order exists yet. Insertion that relies on a prior read without a uniqueness constraint does not win that race.[1]

The outcome is not just two orders. Inventory is deducted twice.

If you shrink the problem to “the user double-clicked,” the fix stops at disabling the button. In practice, identifying whether attempts belong to the same order, ensuring exactly one order is confirmed, deducting inventory once, and preventing downstream systems from running the same work again are separate responsibilities.

Retries of the same order are not the same as different orders#

Start by separating two scenarios.

• Retransmission of the same order attempt: Response loss, timeouts, app restarts, or duplicate clicks can deliver one logical order request to the server multiple times. Idempotency is the API property of handling such retries without duplicate side effects.[2][5]
• Competition between distinct valid orders: Two customers order the last unit at the same time. Here you need to control concurrent updates to the inventory row, not reuse a request key.[4]

Both look like inventory problems, but they are not the same failure mode. A retry of the same order must be processed once; different orders must compete fairly without overselling.

An idempotency key asks: “Have we already handled this same order attempt?” Locks and conditional updates ask: “Is it safe to change this inventory right now?”

One does not replace the other.

The same order attempt needs an identifier#

POST /orders is a mutating API that easily creates two orders when the same request is sent twice. When the user taps order, the client should mint an idempotencyKey and send the same key for every retry of that attempt.

An API can use a stable Idempotency-Key header so retries of POST or PATCH do not repeat side effects—provided the server stores and enforces the key; support is API-specific and the header is non-standard.[5] The same key is only for the same retry chain; a new order attempt must use a new key.[5]

Without that distinction, teams often invent rules like:

If the same customer orders the same product again within five minutes, treat it as a duplicate.

That sounds safe but blocks legitimate orders. People buy the same product twice. They may split checkout or order again for a gift. Customer + product + a short window guesses at duplication; it does not prove intent.

An idempotency key names the attempt the user started. Storing the key alone is not enough: you must reject a new payload under the same key (e.g. different quantity or address). Keep a fingerprint of core fields and return an error when the same key arrives with a different request.[5]

processing is neither failure nor success#

For requests under the same key, you need at least four outcomes:

If you blur these states, the second request may fabricate success—or create another order.

A timeout is not immediate failure. The server may have finished the order and inventory deduction but lost the response. An external payment call may have reached the processor with an unclear outcome. Stripe advises retrying with the same key and parameters after network errors, and reconciling or confirming the original result before starting new work when the outcome is unclear.[7]

So processing and unknown may look awkward in the UI, but they must not be hidden. The user should see something like “Checking whether your order was accepted” and be able to poll order status. The system must not create a new order in the meantime.[2][7]

Check-then-insert is not a guarantee under concurrency#

Even with an idempotency key, this implementation is unsafe:

SELECT * FROM orders WHERE idempotency_key = :key

-- if no row
INSERT INTO orders (...)

Two transactions can both see no row. “We observed no duplicate” is a momentary fact, not a promise for the next instant.

The rule “exactly one order” must be enforced by the database.

CREATE UNIQUE INDEX uq_order_request
ON orders (customer_id, idempotency_key);

Let the database decide conflicts:

INSERT INTO orders (customer_id, idempotency_key, request_hash, status)
VALUES (:customer_id, :key, :request_hash, 'processing')
ON CONFLICT (customer_id, idempotency_key) DO NOTHING;

Only the insert that succeeds proceeds with order handling. On conflict, read the existing row and return processing, confirmed, rejected, or unknown as appropriate.

PostgreSQL documents ON CONFLICT for specifying behavior on uniqueness violations.[1] Here the constraint’s job is clear: prevent two confirmed orders for the same request key.[1]

Do not put this index on customer_id + product_id. That enforces a different product policy—“you cannot buy the same product twice”—not idempotency.

Inventory deduction is a separate integrity rule#

Now two different customers order the last unit. Their idempotency keys differ, so you must not treat one as a duplicate of the other.

Inventory is safer when the database judges current stock and deduction conditions in one step, rather than reading in application code and writing later.

UPDATE inventory
SET available_quantity = available_quantity - :quantity
WHERE product_id = :product_id
  AND available_quantity >= :quantity;

One affected row means success; zero means insufficient stock. This conditional update re-evaluates against current state at write time.[4]

Pessimistic or optimistic locking are also options. Complex rules—reservations, multi-line orders, quantity math—may require locking a row and processing serially. PostgreSQL notes explicit locking when MVCC alone is not enough.[4]

Locks alone do not stop re-execution of the same order attempt. After the first request deducts inventory and completes, a retry can acquire the lock and deduct again.

Locks address inventory contention; idempotency keys address duplicate requests.

How much to put in one transaction#

If order rows and inventory live in the same database, start by wrapping both in one transaction.

1. Acquire exactly one processing order row via the idempotency key.
2. Run conditional inventory deduction.
3. On success, move the order to confirmed.
4. On insufficient stock, move the order to rejected.
5. Commit.

That reduces intermediate states like “order succeeded but inventory failed” or “inventory dropped with no order.”

When the payment processor is external, you cannot finish everything in one DB transaction. Whether to reserve at authorization, deduct after payment success, or when to release reservations is product policy—not a database feature. Without that policy, even the “right” locking model produces a shaky checkout experience.

A safe order API still leaves downstream steps#

After persisting the order, you may emit events to inventory, payment, shipping, and notifications. Duplication risk moves to those systems.

The DB commit can succeed and the process dies before publishing. Or an event goes out and the DB rolls back. Transactional outbox puts order changes and event records in the same DB transaction to reduce dual-write problems.[6]

Outbox does not make every downstream handler run exactly once. Messages can be delivered more than once.[3][6] Consumers for reservation, payment, and shipping must persist processed event IDs and reuse or skip on redelivery.[3]

Order API idempotency and consumer idempotency are contracts at different layers.

“Can’t we just use a Redis lock?”#

A distributed lock (e.g. Redis) can serialize work per product. As the sole source of truth, you inherit lock expiry, network partitions, lost ownership, and failures after taking the lock but before committing to the DB.

Distributed locks can reduce contention in a critical section. Confirming one order is still most directly enforced with DB uniqueness; inventory floors are still most directly enforced with conditional updates or DB locks. Locks should complement those rules, not replace them.

What must happen exactly once?#

Preventing duplicate orders is not picking one technique. You need answers to:

1. Does the same order attempt carry a stable identifier across retries?
2. Is that identifier protected by a DB uniqueness constraint?
3. For the same key in processing, success, rejection, or unknown, do you return distinct, correct responses?
4. When different orders compete, do conditional updates or appropriate locks prevent negative inventory?
5. Are order confirmation and inventory deduction bundled atomically where they share a database?
6. If payment, shipping, or notification events redeliver, do consumers avoid repeating side effects?
7. Does every new order get a new key?

Code that stops duplicate orders is not code that disables a button. It is code that makes the system prove—separately—same order vs new order, stock remaining, and whether downstream work already ran.

References#

• [1] PostgreSQL — INSERT / ON CONFLICT
• [2] AWS Well-Architected — Design idempotent operations
• [3] Microservices.io — Idempotent Consumer
• [4] PostgreSQL — Explicit Locking
• [5] MDN — Idempotency-Key
• [6] AWS Prescriptive Guidance — Transactional Outbox
• [7] Stripe — Advanced error handling

AI writes code. Another AI reviews that code.

That is familiar now. Large PRs land; an AI reviewer leaves dozens of comments. The author may not have typed every line; the human reviewer may not read the full diff. AI produces plausible summaries and fix suggestions.

Then someone asks:

Why did you choose this structure?

What existing behavior changes because of this?

If this fails in production, which data and users are affected?

Why does passing this test mean we are safe?

If nobody can answer well, you did not do code review. You performed a ritual of machines echoing each other.

When things break, the dangerous sentence is not “AI wrote this code.” It is “I did not write this code.”

Review bottlenecks are not only “humans are slow”#

The objection is obvious: line-by-line human reading will not scale with AI-generated volume.

Research on traditional review also does not claim humans catch every serious bug. Much feedback targets evolvability—maintainability, readability, structure, docs—more than catastrophic functional defects.[8] As change size grows, comment density falls; review effectiveness ties closely to review size.[7]

AI clearly helps here: repetitive violations, type errors, risky dependencies, missing-test candidates, blast-radius hints, and rule violations faster than humans alone. Studies on AI code review show promise for functional issues and noise reduction when combining multiple independent reviews.[4]

This is neither an argument for banning AI review nor a demand that humans read and approve every diff.

The trap is believing that faster generation automatically expands understanding, verification, and accountability.

AI review leaves comments; code review must leave accountability#

Evidence that AI-only review has fully replaced human review is thin.

A 2026 study of code-review agents analyzed 3,109 PRs from the AIDev dataset. PRs with AI reviewers only merged at 45.20%; human-only review merged at 68.37%. AI-review-only PRs also showed higher discard rates.[1]

Those numbers alone do not prove AI causes failure—harder changes might get AI-only review. They do not support “AI reviewed it, so drop human review.”

Signal quality matters more. Among discarded AI-review-only PRs, 60.2% had meaningful feedback below 30%; 12 of 13 AI reviewers studied averaged signal ratios under 60%.[1]

Many AI comments ≠ safer shipping.

LLM review struggles are not only “the model cannot read code.” Real PR review needs context outside the diff: repo structure, past design decisions, operational constraints tests do not encode, team agreements, customer-facing behavior.

SWR-Bench, using 1,000 real PRs with full-project context, concluded current AI review tools do not reach adequate performance in realistic settings. Top setups suffered low precision—many false positives—and verification cost returns to humans.[4]

AI can say “this value may be null.” It struggles with “null is acceptable for backward compatibility with last year’s app” or “this change’s cost under next week’s promo traffic” from a snippet alone.

Worse than what AI misses is what humans stop looking for#

Showing AI review first can feel like it helps humans review better. It can also narrow attention.

In a controlled study of 29 professional developers, reviewers who saw automated review first focused on locations the AI flagged. Automation found more low-severity issues but not more high-severity ones. Review time did not shrink.[14]

That does not make AI review useless. It means when AI sets the starting frame, human review can shrink to that frame.

That shift is quiet:

• Authors may not understand AI-generated code deeply.
• Reviewers spend time clearing AI comments.
• Design, data, operations, and customer impact AI never mentions fall off the checklist.
• Nobody owns the full meaning of the change.

So the key question in the AI era is not “how many bugs did AI catch?”

Is there a person who knows why we are making this change, what changes, and who recovers if it fails?

Peer review built shared ownership, not just bug detection#

Code review is technical and social.

Work on accountability in code quality describes traditional peer review as expanding individual responsibility into collective responsibility. Authors explain decisions to peers; reviewers question and participate. Personal standards, professional diligence, pride in good code, and reputation within the team underpin that accountability.[2]

That work warns LLM-based review can weaken the mutual accountability structure. You owe an explanation to a colleague later; you are not required to explain to an LLM. An LLM is not on call when production breaks and does not decide recovery for live customers.[2]

“AI reviewed it” is not a quality guarantee. With no accountable owner, it can blur responsibility.

That is not because AI is bad—it is because teams added AI without redesigning who owns what.

Professionals protect the company they have now, not only the model they hope for later#

AI will likely improve. The band where humans need not read every implementation line will grow.

Some argue for the end of human code review: agents can pursue defect detection, style, knowledge transfer, and team awareness cheaper and faster; humans re-reading all AI code does not scale.[10]

Take that seriously. Human review is imperfect; AI output volume exceeds old habits.

But sacrificing today’s quality and accountability for a hypothetical fully automated future is different.

METR’s 2025 randomized controlled trial had 16 experienced open-source developers complete 246 real tasks. Work allowed to use AI took 19% longer on average. Participants believed AI made them faster; measurement did not.[5]

That does not mean AI always slows developers—METR does not generalize to every task or team.[5] Other work finds faster initial implementation with AI and no clear penalty when others extend that code.[6]

So the lesson is not “never trust AI.”

Teams that do not separate what AI is already reliable for from what humans must own are taking the wrong risk.

If you are paid to ship, you cannot hollow out today’s quality process on faith in tomorrow’s cheap perfect model. Professional duty is not predicting model curves—it is making current systems explainable, recoverable, and improvable when they fail.

Reviewers in the AI era should not read every line#

The answer is not more diff for humans.

Mechanically verifiable work belongs in code and automation:

• lint, format, typecheck
• build and tests
• vulnerable dependencies, secrets, license checks
• static analysis
• changed files and dependency impact exploration
• candidate rule violations
• functional decomposition and summary of large diffs

AI can help surface issues humans might otherwise miss.

These still need a human name on the decision:

• why this change is needed now
• what existing behavior changes
• impact on users, data, operations, cost
• residual risk even when tests pass
• how you detect failure and roll back
• who understood the risk and approved

So AI-era PRs need a change accountability brief before—or at least alongside—the code diff:

1. Why — problem being solved
2. What changes — add/modify/delete
3. Blast radius — users, data, APIs, ops, cost
4. Behavior delta — compatibility implications
5. Evidence — tests, logs, runs, runbooks used to verify
6. Risk and rollback — detection and reversal
7. Approver — who understood and signed off

This is not a cosmetic template. It restores understanding and ownership teams lose when AI increases code volume.

Closing#

AI can write code and AI can review it; that share will grow.

After an incident, “the AI suggested it” does not restore service for customers, teammates, or the business.

Code review in the AI era cannot remain “read every line.” It must become clearer: AI explores, checks, summarizes, and proposes; humans own intent, impact, risk, recovery, and final accountability.

A professional is not someone who blindly distrusts AI-generated code.

They design what to automate and what humans must own so the company keeps sustainable quality even as models improve.

Sources#

[1] https://dl.acm.org/doi/full/10.1145/3793302.3793614 [2] https://arxiv.org/html/2502.15963v1 [4] https://arxiv.org/html/2509.01494v1 [5] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study [6] https://arxiv.org/abs/2507.00788v2 [7] https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/iet-sen.2020.0134 [8] https://pmc.ncbi.nlm.nih.gov/articles/PMC9489594 [10] https://arxiv.org/html/2606.13175v1 [14] https://arxiv.org/html/2411.11401v1