Польовий
посібник

Клієнт генерує ключ (UUID v4) для кожної дії, що змінює стан, і надсилає його в заголовку Idempotency-Key. Сервер у тій самій транзакції, що й зміна, записує ключ і результат. Повторний запит із тим самим ключем повертає збережений результат без повторного виконання.

Типові помилки: генерувати ключ на сервері (тоді повтор отримує новий ключ); зберігати ключ поза транзакцією (тоді збій між операціями ламає гарантію); не обмежувати час зберігання (тоді таблиця росте без кінця — 24–72 години зазвичай достатньо).

Останній запис перемагає. Просто, але тихо втрачає дані. Прийнятно для налаштувань, неприйнятно для замовлень.

Черга операцій. Пристрій зберігає не стан, а намір («додати 2 одиниці»). Сервер застосовує операції по черзі й може відхилити неможливі. Найкраще для обліку.

CRDT. Структури, що зливаються без конфліктів. Добре для спільного редагування тексту, надлишково для більшості бізнес-форм.

Правило вибору: якщо втрата одного редагування коштує гроші — черга операцій.

Таблиця лише на дописування: кожен запис містить дані зміни, автора, час і hash = sha256(prev_hash ‖ payload). Права на UPDATE і DELETE для таблиці відкликано. Раз на добу останній хеш експортується в незалежне сховище (наприклад, окремий бакет з блокуванням об’єктів).

Цього достатньо, щоб виявити підробку історії. Розподілений реєстр має сенс лише тоді, коли кілька незалежних сторін не довіряють одному оператору.

• Номер версії і збірки збільшено
• Декларації App Privacy / Data safety відповідають SDK у збірці
• Посилання на політику конфіденційності відкривається без входу
• Тестовий акаунт для рев’ю працює
• Видалення акаунта доступне в застосунку
• Міграція локальної бази перевірена з попередньої версії
• Поетапне розгортання: 5% → 20% → 100%
• План відкату на сервері, якщо API змінювався