Why Missing Idempotency Turns Harmless Retries Into Duplicate Charges

In distributed systems, network timeouts leave clients unable to tell whether a request succeeded or failed, making retries unavoidable rather than optional. This ambiguity becomes dangerous when the underlying operations are not idempotent — meaning repeated execution changes the system state each time, as with adding to a balance instead of setting it. Common infrastructure like HTTP POST endpoints, message queues with at-least-once delivery, and database writes all expose this risk if idempotency is not deliberately designed in. Real-world consequences include customers being charged twice for a single order, duplicate emails, and repeated database inserts — none of which require a coding bug to occur. Idempotency is ultimately a design property of how operations are structured, not a retry mechanism, and must be enforced at the application layer rather than delegated to the network or queue.