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