A retry is a second write until you prove otherwise

The network times out after a mobile client submits a payment, books an appointment or changes an account setting. The interface has no response, so the obvious recovery is to retry.

That retry is safe only if the first request failed before the server committed it. The client cannot know that. A response can disappear after the write succeeds, which means the second request is not a recovery. It is another write.

This is why retry is not merely a networking setting. It is a product decision about what may happen twice.

The weak design says retry on timeout. The stronger design classifies operations first. Reads can usually repeat. Writes need an idempotency key, a version check or a server operation whose result is naturally stable when repeated. The client sends the same key for every attempt. The server records the first completed result and returns it again instead of performing the action twice.

The important question is not whether the endpoint supports retries. It is what identity makes two attempts the same action.

Ask that before choosing a retry policy. What is the unit the user intended once? How long does that identity remain valid? What response should a second device receive? What happens if two different changes use the same stale version?

A polished mobile interface can hide latency and reconnect automatically. It cannot turn an ambiguous write into a safe one. That guarantee has to exist at the boundary where the decision becomes permanent.

In a system design round, name the retry rule beside the write path. In production, test the case where the server commits and the response never arrives. If the second attempt creates a second outcome, the retry mechanism is the bug.