1 iPhone Left. 10,000 Users Click Buy. What Happens? The System Design Answer Every Engineer Should Know

Imagine this.

It's Flipkart Big Billion Day.

An iPhone is available at an unbelievable discount.

Only 1 unit remains in inventory.

Suddenly, 10,000 users click the Buy button at exactly the same moment.

Simple question:

Who gets the iPhone?

Most developers answer:

"The first user gets it."

Unfortunately, that's not how real distributed systems work.

And understanding why reveals one of the most important concepts in System Design.

What Actually Happens?

Let's assume your backend follows this simple flow:

Read Inventory

Check if Stock > 0

Create Order

Reduce Inventory

Current inventory:

stock = 1

Now imagine:

10,000 requests arrive simultaneously

Every request reads:

stock = 1

before inventory gets updated.

As a result:

Request 1 sees stock available

Request 2 sees stock available

Request 3 sees stock available

Request 4 sees stock available

...

All 10,000 requests believe inventory exists.

The result?

❌ 10,000 orders created

❌ Only 1 iPhone available

❌ Massive overselling problem

The Real Problem: Race Condition

This issue is called a Race Condition.

A race condition occurs when multiple requests access and modify the same data at the same time.

The dangerous flow looks like this:

Read Stock ↓ Validate Stock ↓ Create Order ↓ Update Stock

Between the Read and Update steps, another request can enter.

Then another.

Then another.

Under heavy traffic this becomes a disaster.

How Amazon and Flipkart Prevent Overselling

Real e-commerce companies never trust normal database checks.

Instead, they use atomic inventory operations.

Solution #1: Redis Atomic Decrement

One of the most common solutions uses Redis.

Instead of:

if(stock > 0)

companies use:

DECR inventory

Redis executes commands atomically.

Meaning:

Only one request can modify the value at a time.

Example

Initial stock:

stock = 1

User A performs:

DECR

Result:

stock = 0

✅ Success

User B performs:

DECR

Result:

stock = -1

❌ Rejected

No overselling occurs.

But What If Redis Crashes?

This is where senior engineers think differently.

A strong system design answer should discuss:

Replication

Persistence

Failover

Distributed Locking

Inventory Recovery

Because inventory is business-critical.

Solution #2: Inventory Reservation

Many modern systems don't immediately sell inventory.

Instead they reserve it.

Reservation Flow

Reserve Inventory ↓ Process Payment ↓ Payment Success ↓ Confirm Order

If payment fails:

Release Inventory

This prevents inventory from being locked forever.

Solution #3: Queue Everything

Imagine:

1,000,000 users

trying to buy simultaneously.

Your database cannot handle that directly.

Instead companies use:

Users ↓ Load Balancer ↓ API Servers ↓ Message Queue ↓ Inventory Service ↓ Database

Popular technologies:

Kafka

RabbitMQ

Amazon SQS

Queues absorb traffic spikes and protect databases.

What Interviewers Actually Want

Most candidates focus on:

Who gets the iPhone?

But interviewers care about:

Concurrency

Atomicity

Scalability

Fault Tolerance

Distributed Systems

Inventory Consistency

The real question is:

How do you prevent overselling when thousands of requests arrive simultaneously?

Follow-Up Questions You Should Be Ready For

A good interviewer may ask:

What happens if payment fails?

What happens if Redis crashes?

How do you prevent bots?

How do you ensure fairness?

How do you handle 1 million requests per second?

How do multiple data centers synchronize inventory?

These questions separate average engineers from strong system designers.

Real Flash Sale Architecture

A simplified architecture looks like:

Users ↓ CDN ↓ Load Balancer ↓ API Gateway ↓ Redis Inventory Layer ↓ Message Queue ↓ Order Service ↓ Payment Service ↓ Database

The key idea:

Reject invalid requests as early as possible.

Because during a flash sale, more than 99% of requests will fail anyway.

Why Companies Love This Interview Question

This single question tests:

Concurrency

Distributed Systems

Scalability

Caching

Queues

Consistency

Fault Tolerance

Architecture Thinking

In just one scenario.

That's why companies like Amazon, Flipkart, Meesho, Walmart, and Swiggy frequently ask similar questions during backend and system design interviews.

Final Thoughts

At first glance:

1 iPhone

10,000 Users

looks like an inventory problem.

In reality:

it's a distributed systems problem.

The difference between:

stock = 1

and

oversold by 10,000 units

can be a single race condition.

And that's exactly why companies spend millions building highly scalable inventory systems.

The next time someone says:

"The first user gets it."

You'll know why the real answer is much more interesting.

Key Takeaway

In large-scale systems:

Correctness > Speed

because one race condition can cost millions of dollars.

And that's the mindset interviewers are actually looking for.