Day 28: Soft Reservations and Expiry – The Digital Bouncer for Your Inventory

Welcome back, architects and engineers! Today, we're diving into a critical system design pattern that separates the good systems from the truly resilient, hyperscale ones: Soft Reservations and Expiry. Think of it as a digital bouncer for your inventory, holding a spot for a VIP for a few minutes, but quickly letting someone else in if they don't show up.

In our journey to build systems handling 100 million requests per second, every millisecond counts, and every item in your inventory is precious. We've covered Circuit Breakers (Day 20) to handle cascading failures. Now, let's tackle a different kind of fragility: the implicit "hold" consumers expect during checkout, and the chaos that ensues if that hold isn't managed properly.

The Intuition: "Hold My Item, Please!"

Imagine you're buying concert tickets online. You find the perfect seat, click "Buy Now," and it takes you to the payment page. For those few minutes you're entering your credit card details, you expect that seat to be held for you. You'd be furious if, mid-transaction, it suddenly became unavailable.

This is the core problem:

1. Limited Inventory: Many items are scarce (concert tickets, limited edition products, hotel rooms).

2. User Experience: Users expect a temporary lock on an item during a critical transaction phase (e.g., checkout).

3. Abandonment: Users often abandon carts or fail payments. If we hard-reserve an item immediately, it's stuck until manual intervention or a very complex rollback.

4. Race Conditions: Multiple users trying to buy the last item simultaneously.

Soft Reservations are the elegant solution. We temporarily "earmark" an item without fully deducting it from our available stock. If the user completes the purchase within a set timeframe, the hold is converted into a confirmed sale. If not, the hold expires, and the item is automatically returned to the general inventory, ready for the next customer. This minimizes lost sales due to abandonment and improves inventory efficiency.

Core Concepts: System Design & Architecture

At 100M requests per second, directly locking database rows for every potential purchase is a non-starter. We need a highly concurrent, eventually consistent approach.

The SoftHold as a First-Class Citizen

Instead of just decrementing inventory, we introduce a new entity: the SoftHold. This entity represents a temporary claim on an item.

System Components & Their Roles:

1. Checkout Service (Orchestrator):

• Initiates the SoftHold request when a user begins checkout.

• Calls the Reservation Service to create the hold.

• If payment succeeds, calls the Reservation Service to confirm the hold.

• If payment fails or user abandons, it might explicitly tell Reservation Service to release the hold, or rely on expiry.

1. Reservation Service (Our Focus):

• Manages the lifecycle of SoftHold entities.

• Exposes APIs to createHold, confirmHold, releaseHold.

• Interacts with the Inventory Service to check availability and, crucially, to update on_hold_stock and available_stock.

• Insight: The Reservation Service should be distinct from the Inventory Service. This allows independent scaling and ensures separation of concerns. Inventory Service focuses on absolute stock truth, Reservation Service on temporary claims.

1. Inventory Service: