Should React Native apps rely on server-side idempotency keys or client-side deduplication to prevent duplicate writes on retry?

The goal is to guarantee that a network mutation (e.g., a payment or form submission) is processed exactly once on the server, even when the request is retried after a timeout, network failure, or app restart.

Constraints include deciding where the idempotency key originates and how it is persisted (client‑side storage like AsyncStorage versus server‑side storage with TTL), handling offline queue drainage after a reinstall, and ensuring the server actually deduplicates on the key. Uncertainty remains about which approach provides stronger guarantees across device changes and app reinstalls without introducing duplicate writes or extra complexity.

Should the client generate and persist a UUID‑based idempotency key and rely entirely on the server to deduplicate retries? Should the client instead maintain an offline queue that guarantees exactly‑once delivery and treat the server key as a fallback? Is a hybrid approach—client‑side key generation with server‑side enforcement and a bounded TTL—necessary to cover all failure scenarios?