Idempotency: surviving the retry

The retry that charges twice

The app fires POST /bookings. The server creates the booking, charges the card, and sends 201... but the response is lost on a flaky subway connection. The app never hears back, so it does the sensible thing and retries. Now you have two bookings and two charges for one walk.

This isn't a rare edge case — it's how networks work. Any client that retries (and every good one does) will eventually send you a duplicate. For a read that's harmless; for a write that moves money, it's a double charge. The property you need is idempotency: the same request sent twice has the same effect as sending it once.

The senior line: at-least-once delivery is the only honest assumption about a network. So any money-moving POST has to be idempotent — the second attempt must be a no-op that returns the first result.