Skip to main content
استخدم سطح دورة الحياة عندما تعكس الذكريات سجلات تملكها قاعدة بياناتك — صفوف CRM، حقول الملف الشخصي، التذاكر. على عكس save التي تُضاف فقط، لهذه الذكريات هوية مُستدامة وتاريخ إصدارات، بحيث تُطبَّق التصحيحات والحذف من مصدر الحقيقة مرة واحدة بالضبط، بالترتيب، مهما كانت الفوضى في التسليم.

نموذج الهوية

ذاكرة مملوكة للمصدر تُعرَّف بواسطة (endUserId, source, externalId). يجب أن يزداد version كلما تغيّر سجل المصدر.

ضمانات التسليم

الطفرات متزامنة، والقواعد بسيطة:
  • إعادة محاولة نفس الإصدار + الحمولة تُعيد نفس الإيصال المُستدام. إعادة الإرسال بعد عطل آمنة — هذه هي قصة التعافي من الأعطال.
  • حمولة مختلفة لإصدار موجود تُعيد 409. الإصدارات غير قابلة للتعديل.
  • إصدار أقدم متأخر يُعيد 409 ولا يكتب أبداً فوق محتوى أحدث أو يُحيي ذاكرة محذوفة.
يتبع الحذف نفس الإصدارات:
الحذف مُستدام: تتقارب إعادات المحاولة إلى الإيصال الأصلي، ولا يمكن لعمليات upsert المتأخرة بإصدارات أقل إعادة إنشاء الذاكرة.

التمهيد باستخدام outbox

انعكس السجلات الموجودة بشكل مجمّع عبر lifecycleBatch — حتى 100 عنصر و1 ميبايت من المحتوى الإجمالي لكل استدعاء. لا توجد مهمة استيراد من جانب الخادم؛ صندوق outbox من جانب العميل يُعيد الإرسال بعد عطل هو قصة الاستئناف بأكملها:
result.success يعني فقط “تمت معالجة الدفعة” — تحقق دائماً من النتائج لكل عنصر. علِّم صفاً كمنجز عند success أو stale_source_version (كلاهما يعنيان أن الإصدار دائم بالفعل)، ثم أرسل الدفعة التالية.

القراءة مرة أخرى

GET /api/v1/memories/{externalId} يُعيد الذاكرة وأحدث إيصال مُطبَّق — مفيد للتحقق من التقارب بعد الترحيل.