How do you design the inventory management component?

Direct Answer

Inventory management requires a separate Inventory entity tracking availableStock and reservedStock for each product. When a user adds items to cart and proceeds to checkout, the system calls reserveStock atomically (using database row-level locking or optimistic locking with a version field) to decrement available and increment reserved. This prevents overselling when multiple users buy simultaneously. On successful payment, convert reserved to sold (decrement reserved). On order cancellation or timeout, return reserved stock to available. For multi-warehouse setups, Inventory has a warehouseId field, and allocation algorithms pick the optimal warehouse based on customer location.

Deep Dive & Architecture

Stock is governed by an invariant

For one product and warehouse, the quantities must never become negative, and committed plus reserved stock must not exceed the stock received. The Inventory aggregate owns these numbers so checkout code cannot alter them independently.

Reservation separates intent from sale

Checkout requests reserve(productId, quantity, reservationId). The operation atomically reduces available stock and increases reserved stock. Payment success confirms the reservation and consumes it; cancellation or expiry releases it. The reservation id makes retries safe and gives a cleanup job something specific to expire.

Concurrency is tested with the last unit

Suppose available stock is one and two buyers reserve it at the same time. An optimistic version check or a database update such as UPDATE ... WHERE available >= 1 lets exactly one request change the row. The other receives an out-of-stock result instead of creating negative inventory. In a multi-warehouse system, allocation chooses a warehouse first, but the selected warehouse still performs the same atomic reservation locally.

Code Example

class Inventory {
    private final String productId;
    private int available;
    private int reserved;
    private int version;                  // optimistic lock token

    // returns false if not enough stock OR a concurrent update bumped the version
    synchronized boolean reserve(int qty, int expectedVersion) {
        if (version != expectedVersion) return false;   // someone else changed it -> retry
        if (qty > available) return false;               // would oversell
        available -= qty;
        reserved  += qty;
        version++;
        return true;
    }
    synchronized void confirm(int qty) { reserved -= qty; }          // payment succeeded
    synchronized void release(int qty) { reserved -= qty; available += qty; } // failed/expired
}

Reserve on checkout, confirm on payment, release on failure — the version field detects concurrent edits.

Common Mistakes & Pitfalls

• Single stock count, decrement on payment — two buyers both pass the check and oversell.
• No reservation release — abandoned carts lock stock forever.
• Ignoring concurrency entirely — say how you make reserve atomic (lock or version).
• Reserving on add-to-cart — too early; reserve at checkout, or low-stock items vanish from everyone's view.