أكثر أوضاع الفشل ترويعاً في نظامٍ موزَّع ليست طلباً يفشل بصخب. بل طلبٌ يفشل بصمت ثمّ يُعاد. شحنتان تُحجزان بنيّة تاجرٍ واحدة. تحويلان ماليّان مقابل طلبٍ واحد. Webhooks اثنان يُولّدان سجلَّين سيُربكان موظّف الدعم إلى الأبد.

العادة

قبل أن تكون ترويسةً، الـidempotency عادة. كلّ نقطة كتابةٍ تسأل نفسها: إن استُدعِيتُ مرّتَين بنيّةٍ واحدة، هل أُنتِج نتيجةً واحدة؟ يقود هذا السؤال تصميم الجداول (مفاتيحُ طبيعيّة، وقيود تفرّدٍ على النيّة لا على الـid الداخليّ)، وسياسات إعادة المحاولة، وشكل الواجهة البرمجيّة نفسه.

وحده بعد تكوّن العادة يبدأ إضافة ترويسة Idempotency-Key على السلك في كسب حقّه في الوجود. الترويسة تجعل الوعد صريحاً للمُستدعي؛ العادة هي ما تجعل الوعد صادقاً.

أين تنزلق الفرق عادةً

الخطأ الأشيع أن يُعامَل الـidempotency مسؤوليّةَ عمّال الطابور فقط. يجب أن يصمد عند المدخل — لحظة وصول الـwebhook، قبل أن يتفرّع إلى مهامّ، قبل أن يمسّ الحالة. وإلّا تحوّل ackٌ بطيءٌ إلى سجلٍّ مكرَّرٍ على عمق عاملَين.