DSA & System Design
All the basics

What is idempotency?

Doing the same request twice has the same effect as doing it once, so retries and double taps are safe.

A PAID stamp on a receipt: stamp it a second time and it still says paid once. A repeat tap should leave things as they are.

Press Play to watch it run · 6 steps

A phone sends a payment to a shop, which charges a card company and remembers payment keys.

Tapping Pay twiceA phone sends a payment to a shop, which charges a card company and remembers payment keys.Your phoneShopSeen keysCard company

Tap any box to see what it is and what it talks to.

  • Client
  • Service
  • Cache
  • External API
Open in playground
Text description
  1. You tap Pay on a slow connection.
  2. The shop charges your card 20 dollars.
  3. The reply gets lost. Your screen still says loading.
  4. You tap Pay again.
  5. The shop sees a new request and charges another 20 dollars.
  6. You are charged 40 dollars for one order.
  • Retries happen, so repeat requests must be safe.
  • Make one unique key per action, and reuse it on retries.
  • A repeat gets the saved result, not a second effect.

Reach for it when

On anything that charges money or creates an order, since a flaky connection makes people tap Pay twice. Reads are already safe.

The catch

The server must store every key and its saved result for a while, and a retry racing the first request needs care.

Say it in an interview“I would make the payment endpoint idempotent: the client sends a unique key, the server stores the result under it, and any retry returns that same result.”