Field
manual

The client generates a key (UUID v4) for each state-changing action and sends it in an Idempotency-Key header. The server records the key and result in the same transaction as the change. A repeat request with the same key returns the stored result without re-executing.

Common mistakes: generating the key on the server (a retry gets a new key); storing the key outside the transaction (a crash in between breaks the guarantee); never expiring keys (the table grows forever — 24–72 hours is usually enough).

Last write wins. Simple, but silently loses data. Fine for preferences, not for orders.

Operation queue. The device stores intent (“add 2 units”), not state. The server applies operations in order and can reject impossible ones. Best for inventory and ledgers.

CRDTs. Structures that merge without conflicts. Good for collaborative text, overkill for most business forms.

Rule of thumb: if losing a single edit costs money, use an operation queue.

An append-only table: each row holds the change, author, time and hash = sha256(prev_hash ‖ payload). UPDATE and DELETE rights are revoked. Once a day the latest hash is exported to independent storage (for example a separate bucket with object lock).

That is enough to detect tampering. A distributed ledger only makes sense when several independent parties do not trust a single operator.

• Version and build numbers incremented
• App Privacy / Data safety declarations match SDKs in the build
• Privacy policy link opens without sign-in
• Review test account works
• Account deletion available in-app
• Local database migration tested from previous version
• Staged rollout: 5% → 20% → 100%
• Server rollback plan if the API changed