Skip to main content
Використовуйте поверхню життєвого циклу, коли памʼять дзеркалить записи, якими володіє ваша база — рядки 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} повертає памʼять і її останню застосовану квитанцію — корисно для верифікації збіжності після міграції.