Використовуйте поверхню життєвого циклу, коли памʼять дзеркалить записи, якими володіє ваша база — рядки CRM, поля профілю, тикети. На відміну від append-only save, ці памʼяті мають довговічну ідентичність та історію версій, тож виправлення та видалення з джерела істини застосовуються рівно один раз, у порядку, як би безлад не був у постачанні.
Модель ідентичності
Памʼять, керована джерелом, ідентифікується за (endUserId, source, externalId). version має збільшуватися щоразу, коли запис у джерелі змінюється.
Гарантії доставки
Мутації синхронні, а правила прості:
- Повтор тієї ж версії + payload повертає ту саму довговічну квитанцію. Повторна відправка після крашу безпечна — це і є історія відновлення після крашу.
- Інший payload для наявної версії повертає
409. Версії незмінні.
- Затримана старіша версія повертає
409 і ніколи не перезаписує новіший контент, ані не воскрешає видалену памʼять.
Видалення підпорядковується тому ж версіонуванню:
Видалення довговічне: ретраї сходяться до оригінальної квитанції, а затримані upsert-и з нижчими версіями не можуть відтворити памʼять.
Бутстрап через outbox
Масово дзеркальте наявні записи через lifecycleBatch — до 100 елементів і 1 МіБ сукупного контенту на виклик. Немає серверного імпорт-джобу; клієнтський outbox, який повторює після крашу, — це вся історія відновлення:
result.success означає лише «пакет опрацьовано» — завжди перевіряйте результати попозиційно. Позначайте рядок як готовий за success або stale_source_version (обидва означають, що версія вже довговічна), потім надсилайте наступний батч.
Читання назад
GET /api/v1/memories/{externalId} повертає памʼять і її останню застосовану квитанцію — корисно для верифікації збіжності після міграції.