How Duplicates Happen
Double-tap impatience
User taps a button once, sees no immediate response, and taps again — sending two identical requests before the first has completed.
Network retry
The first request was sent but the response was delayed or lost. The system retries automatically — potentially reaching the server while the original is still being processed.
Page/form reload
User refreshes a page immediately after submitting a form — the browser may ask to re-send the form data, which resubmits the original action.
Back button submission
User navigates back after submitting and returns to the form, then submits again without realizing the first submission was accepted.
Idempotent vs Non-Idempotent Actions
Online operations can be categorized by whether repeating them produces the same result as performing them once. This property is called idempotency — important because it determines whether a duplicate matters.
Idempotent — safe to repeat
Performing the operation multiple times produces the same result as once. Loading a page, checking a balance, reading data — repeating has no additional effect beyond the first time.
Non-idempotent — not safe to repeat
Each repetition produces an additional effect. Submitting a form, placing an order, making a payment — a duplicate submission could result in two orders or two charges rather than one.
For actions where duplicates matter, well-designed systems include mechanisms to identify and reject repeated submissions. A unique identifier assigned at submission time lets the server recognize a second arrival of the same request. A brief lockout on the submit button prevents rapid re-tapping. A server-side check confirms whether the action was already processed before acting again. Users typically see only the outcome — the action was accepted once — without seeing the duplicate detection that prevented double-processing.
