Place an Order — Why Aren't You Charged Twice?

maang.io System Design Series

What is this?

You've filled your cart, entered your card, and your thumb is hovering over the big Place Order button. You press it. Your finger slips and you press it again. A half-second later your phone's wifi stutters, the app spinner hangs, and somewhere under the hood the client quietly retries the request a third time. Three signals left your device for one intention. And yet — when the receipt lands in your inbox — you were charged once. One order. One payment. One decrement of stock.

That is not luck. It is one of the most important properties a real system can have, and it has a name: idempotency — the guarantee that doing the same operation many times has the same effect as doing it once. This scenario traces a single checkout click end to end, and unlike the URL walk (which was a relay of handshakes), this story has a different spine: every stage is bent around the question "what if this happens twice?"

The one-line idea: a checkout request can arrive more than once — fat-fingered double-clicks, network retries, queue redelivery — so every layer that touches money or stock is built to collapse duplicates into a single effect: the client tags the attempt with an idempotency key, the server remembers that key, the database does the money-and-stock change as one all-or-nothing transaction, and the asynchronous fan-out downstream is made safe to replay.

The order of the stages matters, but the theme matters more. Watch how the same idea — "make duplicates harmless" — shows up at the gateway, in the cache, in the database, and again at the very back of the system in the message queue. Let's follow the click.