Which Inventory Deduction Strategy Is Best for E‑Commerce? Order, Payment, or Pre‑Deduction Explained

Inventory Deduction Strategies in E‑commerce

1. Order‑time deduction

When an order is created, the order service immediately calls the inventory service to decrement the stock. This approach is simple and gives the best perceived latency for the shopper.

Advantages : immediate feedback, minimal code path.

Drawbacks :

Malicious or abandoned orders lock stock, preventing genuine buyers from purchasing.

Legitimate orders that are not paid keep the stock reserved until the order is cancelled, reducing overall sales.

High‑concurrency traffic forces the database to use row‑level locks; many threads block, exhausting the connection pool and causing order‑creation timeouts.

2. Payment‑time deduction

The inventory is not touched when the order is created. Stock is reduced only after the payment gateway reports a successful payment.

Advantages : no stock is held before payment, eliminating the “stock‑hoarding” problem.

Drawbacks :

Under heavy load, many users may complete payment after the available quantity has been exhausted, leading to oversell.

If deduction fails after payment, the system must trigger a refund, which harms user experience and adds operational cost.

The need for a compensation workflow increases overall system complexity.

3. Pre‑deduction (reservation)

This hybrid model freezes a portion of inventory at order creation (often in a dedicated reserved column). If payment succeeds, the reservation is converted into a real deduction; if the order times out, a delayed task releases the reservation.

Typical workflow :

User places an order → order service writes a reservation record (e.g., stock_reserved += qty).

Payment service notifies order service of payment success.

Order service tells inventory service to move the reserved amount to the deducted amount (e.g., stock_reserved -= qty; stock_available -= qty).

If payment does not arrive within the configured timeout, a reliable delayed job (cron, time‑wheel, or message‑queue delay) releases the reservation.

Benefits :

Better user experience – the shopper sees the item as available while the system protects against oversell.

Reduces database contention during flash‑sale spikes because the reservation step can be performed in memory (e.g., via Redis) and only persisted asynchronously.

Complexities :

Ensuring eventual consistency requires a robust delayed‑task mechanism; failures in the release process can cause “ghost” reservations.

Distributed transactions span order, payment, and inventory services; compensation logic must handle partial failures.

Cache‑database synchronization is critical. A common pattern is to keep the authoritative stock in Redis with a write‑through to the relational store, but cache invalidation must be carefully designed to avoid stale reads.

4. Selecting the appropriate strategy

Order‑time deduction : best for ultra‑high‑throughput flash‑sale events where any oversell is unacceptable and the business can tolerate the lock‑contention overhead.

Payment‑time deduction : suitable for virtual goods (e.g., digital courses, software licenses) where physical inventory does not exist, allowing maximum concurrency without reservation logic.

Pre‑deduction : the default choice for most regular e‑commerce products, offering a balance between user experience and inventory safety.