High SeverityConcurrencyRace Condition

Double-Buy Protection

1.The Symptom (The Chaos)

The database cleanly ended up at stock = 0, but we accidentally charged two separate credit cards for one single physical t-shirt.

2.The Trigger Condition

Two high-speed checkouts hit our API at the exact same millisecond window. Both separate threads read stock = 1 simultaneously before either could finish saving their update loop.

3.The Catch (Why it broke)

We trusted our distributed application servers to validate the stock availability in memory, instead of forcing the database engine to check and deduct the value natively in an isolated transaction.

4.Architectural Trade-offs

To resolve this, we have to implement row-level database locks during checkout. This keeps our inventory counts perfectly flawless, but introduces a minor latency queue penalty during high-volume flash sales.

InventoryService.java

[Vulnerable Target View]

public void checkout(Long productId, int quantity) {
    Product product = repository.findById(productId).get();
    if (product.getStock() >= quantity) {
        product.setStock(product.getStock() - quantity);
        repository.save(product);
    }
}