Skip to content

How Does Amazon Make Sure You Don't Buy the Same Item Twice?

Refresh the checkout page and you still get one order, one payment, one email. How request identifiers make retries safe at Amazon's scale.

By 2 min read
  • Real System Deep Dive
  • Idempotency
  • E-Commerce
  • System Design
  • Software Architecture

Imagine you're buying a laptop. You click "Place Order." The page keeps loading.

You aren't sure whether it worked. So you refresh and click the button again.

A few seconds later...

  • Only one order appears.
  • Only one payment is processed.
  • Only one confirmation email arrives.

How Does Amazon Make Sure You Don't Buy the Same Item Twice?

That isn't luck. It's architecture.

A simplified checkout flow looks like this:

  1. πŸ›’ You click Place Order.
  2. πŸ”‘ A unique request identifier is created for the checkout.
  3. πŸ’³ The payment request is processed.
  4. πŸ“¦ Inventory is reserved.
  5. 🧾 The order is created.

Now imagine your browser retries the same request because of a timeout. Instead of creating a second order...

The backend recognizes the same request identifier and returns the original result.

  • No duplicate payment.
  • No duplicate shipment.
  • No duplicate order.

This is one of the reasons distributed systems are so fascinating. The user only sees one action.

Behind the scenes, the system may have handled multiple identical requests. One principle I always come back to is this: Users should be free to retry. Systems should be responsible for staying consistent.

That's what separates a feature that works from a platform users can trust.

What's another real-world system you'd like me to break down in this series?

Keep reading