أساس القرار
وصول إشعار لا يعني اكتمال فعل تجاري. صمم للتكرار واختلاف الترتيب. توثق Stripe ذلك لخدمتها؛ افحص عقد كل مورّد آخر.
مثال عملي
يُتحقق من حدث افتراضي «فاتورة مدفوعة»، ثم يحفظ معرّفه والعمل المقصود، ويؤكد بعد قبول دائم. عند التكرار يُعرف الحدث دون قيد مزدوج. يحتفظ الفشل اللاحق بحالة قابلة للإعادة.
البدائل وتبعاتها
يسجل inbox الوارد، وoutbox العمل الناتج من معاملتك. يفصلان النية الدائمة عن الشبكة. تكشف المطابقة اختلافاً ولو لم يبلغ إشعار عن خطأ.
أين تتعثر الخطة
لا تحفظ المعرّفات بالذاكرة فقط ولا تعلن الانتهاء قبل تثبيت التغيير. تعامل مع القديم بالحالة أو النسخة. باعد إعادات الأعطال المؤقتة وحوّل البيانات الباطلة للمراجعة.
افصل هوية التسليم عن هوية العمل
احفظ معرّف الحدث ومرجع الفاتورة. قد تخص أحداث مختلفة فاتورة واحدة؛ حظر الجميع بعد أول ظهور يفقد تغييرات صحيحة. وفي المقابل لا يضيف تكرار الحدث ائتماناً ثانياً. حدّد مفتاح الاستقبال وقيد حالة العمل، وثبّت الفحوص مع التغيير الفعلي.
تحقق من المرسل بآليته الموثقة قبل القبول. إن كان التوقيع للجسم الخام، احفظ البايتات الأصلية بدل إعادة إنشاء JSON. أسرار التوقيع لا تدخل السجلات أو الشيفرة. التحقق والمحاولات والاحتفاظ خاصة بالمورّد؛ نسخ تكامل آخر قد يفحص الشيء الخطأ.
أثبت الاستعادة في اللحظة الحرجة
أوقف العامل بعد الاستلام وبعد القبول الدائم وأثناء تغيير السجل. افحص صندوق الأحداث والسجل التجاري بعد التشغيل. قد يُقبل أثر خارجي قبل حفظ النتيجة محلياً. استخدم منع التكرار أو استعلام المطابقة إن كان مدعوماً؛ علم حالة محلي لا يضمن تسليماً مرة واحدة تماماً.
إعادة التشغيل المضبوطة تحفظ الهوية والسبب. البيانات غير الصالحة دائماً تدخل الاستثناءات، لا محاولات بلا نهاية. تقارن المطابقة السجلات المعتمدة خلال فترة محددة. اتفق على قارئ التقرير ومعالجة العاجل ودليل الإغلاق. طابور بلا مسؤول قد يحفظ البيانات بينما لا يعرف أحد أن العمل توقف.
قبل بدء التنفيذ
هل للتكرار أثر واحد؟ هل يستأنف العامل بعد انهيار؟ هل يُحقق في سجل ويُعاد بأمان؟ اجعل هذه العروض معايير قبول التكامل.