Skip to main content
Використовуйте lifecycle-поверхню, коли спогади дзеркалять записи, якими володіє ваша база — рядки CRM, поля профілю, тикети. На відміну від append-only save, ці спогади мають durable-ідентичність та історію версій, тож виправлення й видалення від source of truth застосовуються рівно один раз, у порядку, як би messy не була доставка.

Модель ідентичності

Source-owned спогад ідентифікується через (endUserId, source, externalId). version має зростати щоразу, коли змінюється запис-джерело.

Гарантії доставки

Мутації синхронні, а правила прості:
  • Повтор тієї самої версії + payload повертає ту саму durable-квитанцію. Повторне надсилання після краху безпечне — це і є історія crash-recovery.
  • Інший payload для існуючої версії повертає 409. Версії незмінні.
  • Затримана старіша версія повертає 409 і ніколи не перезаписує новіший контент і не воскрешає видалений спогад.
Видалення підпорядковуються тому самому versioning:
Видалення durable: повтори сходяться до оригінальної квитанції, а затримані upsert’и з нижчими версіями не можуть відтворити спогад.

Bootstrapping через outbox

Bulk-дзеркальте існуючі записи через lifecycleBatch — до 100 елементів і 1 MiB сукупного контенту на виклик. Немає import-job’ів на сервері; client-side outbox, що повторно надсилає після краху, — це вся історія resume:
result.success означає лише «батч оброблено» — завжди перевіряйте per-item результати. Позначайте рядок як виконаний за success або stale_source_version (обидва означають, що версія вже durable), потім надсилайте наступний батч.

Читання назад

GET /api/v1/memories/{externalId} повертає спогад та його останню застосовану квитанцію — корисно для верифікації сходження після міграції.