Why Can Two People Buy the Last Item at the Same Time?
Two customers click "Buy Now" on the last item in stock at almost the same moment — who gets it? Why transactions and row-level locking, not payment processing, are the hardest part of checkout.
- System Design Explained
- Concurrency
- Transactions
- Database Architecture
- Distributed Systems
(How Large E-commerce Systems Prevent Overselling)
Imagine there's only one laptop left in stock. Two customers click "Buy Now" at almost the exact same moment.
Both receive the request. Both see "1 item available." So... Who gets it?
If both orders succeed, you've just sold the same product twice. This is one of the hardest problems in large-scale systems.
Not because checking inventory is difficult. Because multiple users are trying to change the same data at the same time.
A simplified flow looks like this:
- 🛒 Customer A and Customer B both place an order within the same moment.
- Both requests reach the Order Service.
- The database processes the inventory update as an atomic transaction.
- The first successful transaction reserves the last item.
- The second transaction sees updated inventory and fails gracefully.
Notice what happened.
The application didn't solve the problem. The database guaranteed consistency.
This is why concepts like transactions, row-level locking, optimistic concurrency, and inventory reservation exist.
They're not just database features. They're what prevent real-world business failures.
One lesson that's changed how I think about system design: Reading data is easy. Changing shared data safely is where architecture becomes difficult.
The next time you buy the last item online, remember...
The hardest part wasn't processing your payment. It was making sure no one else bought that same item.
What's another real-world system where concurrency creates surprising challenges?
Keep reading
Why Does One Slow Service Make Your Whole App Feel Slow?
An API that "responds in 1.8 seconds" is rarely slow on its own — distributed tracing breaks a request into spans to show which dependency actually spent the time.
Why Doesn't Your Order Confirmation Wait for Everything to Finish?
Payment, inventory, fraud checks, shipping, notifications — a single "Order Confirmed" doesn't wait for all of them. How publish-subscribe events let one action fan out into independent workflows.
Why "Perfect" Data Isn't Always the Right Goal
Waiting for every replica to agree before responding isn't always the right trade. How production systems choose a consistency level per use case instead of chasing perfection everywhere.