Idempotence is the property that repeating an operation has the same intended effect as performing it once. It concerns the effect of the operation, not whether every invocation returns an identical response.

This distinction matters when a caller cannot determine whether a request completed. A retry repeats an attempt. Idempotence determines what repeating that attempt is allowed to change.

The ambiguous completion problem

A request can reach a server, change state, and commit before its response is lost. The caller observes a timeout while the server has already performed the work. Treating the timeout as proof of non-execution can therefore duplicate the business effect.

Take a request to add 100 to a balance. Repeating the request without additional semantics adds another 100. A request to set a particular field to an agreed value has a different effect when repeated. The operation’s contract, rather than the presence of an HTTP endpoint, determines the distinction.

HTTP defines idempotence in terms of intended server effect and places conditions on automatic retries of non-idempotent methods. A declared method is still a contract that the implementation must honor; the label does not test its behavior.

Identify the business operation

Retry handling needs a definition of sameness. Two transport messages can represent one business request, while two requests with identical amounts can be separate legitimate transactions. Comparing payload values alone does not always distinguish them.

A design can associate repeated submissions with an operation identity and a recorded result. The important boundary is how that identity relates to the committed effect. Recording completion after performing an external action leaves a failure interval in which the action occurred but the record does not yet establish it.

Concurrent submissions expose another boundary. Two workers can both observe that an operation has not completed and then perform it. The coordination mechanism must therefore cover the relevant effect, rather than rely on an unchecked earlier observation.

These are design requirements derived from the failure sequence, not a guarantee supplied by any one retry library.

Acknowledgements describe different handoffs

Messaging systems distinguish acceptance into transport from processing by a consumer. RabbitMQ publisher confirms concern the publisher-to-broker boundary. Consumer acknowledgements concern delivery to the consumer. The two mechanisms do not establish each other’s completion.

The business effect sits at another boundary. A consumer can update an external system and fail before acknowledging its message. Redelivery then presents the same work again. Whether that repetition is harmless depends on the operation’s semantics and recovery design.

Acknowledging before the effect creates a different risk: the message can be considered handled even though the business work has not completed. Neither ordering removes the need to account for failure between the two actions.

Execution platforms do not settle semantics

Serverless execution changes hosting and invocation mechanisms. It does not turn every event into exactly one successful business action. Retry ownership varies across invocation paths, and an error visible to a direct caller can follow full, partial, or absent execution.

The same principle applies to batch restarts and UI automation. Repeating a technical step is safe only when its business effect supports repetition or can be reconciled with an existing result.

What to demonstrate

A meaningful retry trial includes failure before execution, after the effect, and before the caller or broker receives completion. It also includes concurrent duplicates where those are possible in the operating arrangement.

The result should show one agreed business outcome or an explicit recoverable exception. Identical responses are optional; unexplained duplicate effects are not compatible with an idempotence claim.

Idempotence, delivery acknowledgement, and exactly-once processing answer different questions. Naming the boundary and the intended effect makes those questions testable instead of treating a transport success indicator as proof that the business operation occurred exactly once.