Idempotency: Why Retries Need It

A client sends a request to create an order. The server commits the order, but the connection fails before the response arrives. The client now has two bad choices:

The network cannot tell the client which history occurred. The server may not have received the request, may still be processing it, or may have completed it.

Idempotency makes repeated delivery safe by ensuring that applying the same logical operation more than once has the same intended effect as applying it once.

For example:

“Set to OFF” is naturally idempotent. “Toggle” is not.

Idempotency is the bridge between unreliable communication and safe recovery. It does not guarantee that every request succeeds, but it removes the need to choose between silently losing an operation and blindly duplicating its effect.