Retries should not repeat consequences

An absent confirmation does not prove an absent reservation.

Repeat the intention, not the effect

Idempotency means repeating the same operation has the same intended effect as performing it once. Responses and diagnostic logs need not be identical. HTTP defines some methods as idempotent, but a business workflow that creates a booking needs its own explicit retry contract; using POST does not provide one automatically.

A common design associates a caller-scoped operation identifier with request details and a durable outcome. A repeated identifier must mean the same operation, not an unrelated request that happens to share a label.

Fictional reservation ledger

Assume the policy preserves retry records for 24 hours. These are supplied observations, not requests to send:

• I1: At 10:00, Lina’s operation R8 creates reservation B41. The confirmation response is lost.
• I2: At 10:01, the same caller and R8, with the same reservation details, receive the recorded B41 result. The ledger still contains one reservation.
• I3: Two diagnostic entries exist because two attempts reached the service.

What the record supports

I2 supports one intended effect in this observation. I3 does not contradict that: two attempts are not two bookings. The record does not prove behavior under simultaneous attempts, failures while saving state, or retries after retention expires.

Approval needs coordination between recording the identifier and committing the reservation so failures cannot separate them. Changed details under the same identifier should produce a defined conflict, not silently create another booking. Authorization remains necessary when returning a stored result.

Review limit: One successful retry supports the example; it does not establish an unlimited, exactly-once delivery guarantee.