استخدم سطح دورة الحياة عندما تُعكس الذكريات سجلات تملكها قاعدة بياناتك — صفوف CRM، وحقول ملف تعريف، وتذاكر. على عكس save التي تُضاف فقط، هذه الذكريات لها هوية دائمة وسجل إصدارات، لذا تُطبَّق التصحيحات والحذوفات من مصدر الحقيقة بالضبط مرة واحدة، بالترتيب، مهما كان التسليم فوضوياً.
نموذج الهوية
الذاكرة المملوكة للمصدر مُعرَّفة بواسطة (endUserId, source, externalId). يجب أن يزيد version كلما تغيّر السجل المصدر.
ضمانات التسليم
التعديلات متزامنة، والقواعد بسيطة:
- إعادة محاولة الإصدار نفسه + الحمولة نفسها تُعيد الإيصال الدائم نفسه. إعادة الإرسال بعد التعطُّل آمنة — تلك هي قصة التعافي من التعطُّل.
- حمولة مختلفة لإصدار موجود تُعيد
409. الإصدارات غير قابلة للتغيير.
- إصدار أقدم متأخر يُعيد
409 ولا يكتب فوق محتوى أحدث أبداً ولا يُعيد إحياء ذاكرة محذوفة.
يتّبع الحذف الإصدارات نفسها:
الحذف دائم: إعادات المحاولة تتقارب على الإيصال الأصلي، ولا يمكن لعمليات upsert المتأخرة بإصدارات أقل إعادة إنشاء الذاكرة.
التهيئة بصندوق صادر
اعكس سجلات موجودة بشكل جماعي عبر lifecycleBatch — حتى 100 عنصر و1 ميبي بايت من المحتوى الإجمالي لكل استدعاء. لا توجد وظيفة استيراد على جانب الخادم؛ صندوق صادر على جانب العميل يُعيد الإرسال بعد التعطُّل هو قصة الاستئناف الكاملة:
result.success يعني فقط “تمت معالجة الدفعة” — تحقق دائماً من النتائج لكل عنصر. علّم صفاً كمُنجَز على success أو stale_source_version (كلاهما يعني أن الإصدار دائم بالفعل)، ثم أرسل الدفعة التالية.
القراءة مرة أخرى
GET /api/v1/memories/{externalId} يُعيد الذاكرة وآخر إيصال مطبَّق — مفيد للتحقق من التقارب بعد الترحيل.