Disabling a submit button can reduce accidental double-clicks. It does not protect a server from retries after connection loss or manually repeated requests. Persisting one logical operation requires an appropriate server-side contract.
One design binds a retry key to the actual payload. The same key and content identify the same stored operation. Different content reusing that key is not silently accepted as another success. Document key names, lifetimes and error responses in the API contract.
Consider persistence and confirmation together
Checking a key and creating its record must remain reliable under parallel requests. A separate existence check before insertion can leave a race condition. Use the database’s transaction and uniqueness mechanisms.
Test artificial data with at least these cases:
| Requests | Expected business state |
|---|---|
| Same key and content | One operation |
| Same key, different content | Visible conflict |
| Concurrent matching retries | No duplicate creation |
Email delivery is separate. A stored operation can remain valid while its notification is pending. Do not promise successful delivery merely because persistence succeeded. Confirmation should describe the secured state and avoid silently turning retries into additional enquiries.