Idempotency: the details
It matters because networks fail halfway. A phone sends a payment, the reply is lost and the app doesn’t know whether the server processed it. The safe thing is to retry, but only if the server recognizes it as the same operation. The usual solution is an idempotency key: a unique identifier the client generates and sends with the request; the server stores the result under that key and returns it unchanged if it sees the key again.
The same principle applies to queues, webhooks and offline sync, where messages can arrive repeated. Designing each step so that repeating it is harmless turns retries into a reliability tool instead of a source of duplicates.