Nutzen Sie die Lebenszyklus-Oberfläche, wenn Erinnerungen Datensätze widerspiegeln, die Ihre Datenbank besitzt – CRM-Zeilen, Profilfelder, Tickets. Im Gegensatz zu append-only save haben diese Erinnerungen eine dauerhafte Identität und einen Versionsverlauf, sodass Korrekturen und Löschungen aus der Source of Truth genau einmal, in Reihenfolge, angewendet werden – egal wie chaotisch die Zustellung wird.
Das Identitätsmodell
Eine quell-eigene Erinnerung wird durch (endUserId, source, externalId) identifiziert. version muss steigen, wann immer sich der Quelldatensatz ändert.
Zustellgarantien
Mutationen sind synchron, und die Regeln sind einfach:
- Erneutes Senden derselben Version + Payload gibt dieselbe durable Empfangsbestätigung zurück. Erneutes Senden nach einem Absturz ist sicher – das ist die Crash-Recovery-Story.
- Ein abweichendes Payload für eine bestehende Version gibt
409 zurück. Versionen sind unveränderlich.
- Eine verspätete ältere Version gibt
409 zurück und überschreibt niemals neueren Inhalt oder stellt eine gelöschte Erinnerung wieder her.
Löschungen folgen derselben Versionierung:
Das Löschen ist durabel: Wiederholungen konvergieren auf die Original-Empfangsbestätigung, und verzögerte Upserts mit niedrigeren Versionen können die Erinnerung nicht wiederherstellen.
Bootstrapping mit einer Outbox
Spiegeln Sie bestehende Datensätze bulk über lifecycleBatch – bis zu 100 Items und 1 MiB an Gesamtinhalt pro Aufruf. Es gibt keinen serverseitigen Import-Job; eine clientseitige Outbox, die nach einem Absturz erneut sendet, ist die gesamte Fortsetzungs-Story:
result.success bedeutet nur „der Batch wurde verarbeitet” – prüfen Sie stets die Ergebnisse pro Item. Markieren Sie eine Zeile bei success oder stale_source_version als fertig (beide bedeuten, dass die Version bereits durabel ist) und senden Sie den nächsten Batch.
Zurücklesen
GET /api/v1/memories/{externalId} gibt die Erinnerung und ihre zuletzt angewendete Empfangsbestätigung zurück – nützlich zur Verifizierung der Konvergenz nach einer Migration.