تصميم تكاملات SMM API تصمد أمام الفشل

النسخة الأولى من كل تكامل API تفترض المسار السعيد: ترسل طلبًا، فتحصل على استجابة، فيُقدَّم الطلب. لكن الإنتاج يعلّمك خلاف ذلك. فالشبكات تنقطع، ونقاط النهاية تنتهي مهلتها، وأخطر فشل هو الغامض، أي الطلب الذي قد يكون نجح أو لم ينجح قبل أن يموت الاتصال. التصميم لذلك الغموض هو المهمة بأكملها.

عدم التكرار هو الدفاع الأساسي. أرفِق مفتاحًا فريدًا بكل طلب، واجعل الخادم يعامل تكرار ذلك المفتاح كالعملية نفسها، لا كعملية جديدة. عندها تصبح إعادة المحاولة بعد انتهاء المهلة آمنة: فإذا كان الأصل قد مرّ، تستعيد الطلب الموجود بدلًا من خصم مزدوج. وبدون هذا، تكون كل إعادة محاولة مقامرة برصيدك.

أضِف طبقة إعادة المحاولات مع التراجع التدريجي فوق ذلك. الأخطاء العابرة، مثل حد المعدل 429 أو 503 أو إعادة تعيين شبكة، ينبغي إعادة محاولتها بتأخيرات متزايدة وحد أقصى، لا إغراق نقطة النهاية فورًا. أما الأخطاء الدائمة، مثل طلب سيئ 400 أو استجابة رصيد غير كافٍ، فينبغي أن تفشل بسرعة وتُعرَض على إنسان، لأن إعادة محاولتها تهدر الوقت وتحجب المشكلة الحقيقية.

وأخيرًا، سوِّ. سجّل كل طلب واستجابة مع مفتاح عدم التكرار ومعرّف الطلب، وشغّل مهمة دورية تقارن سجلاتك بحالات الطلبات في اللوحة. التسوية هي ما يلتقط الطلب الذي نجح في اللوحة لكنه فشل في التسجيل لديك. تُرجع واجهة API الخاصة بـ SocialGO معرّفات وحالات طلب متسقة تحديدًا حتى يكون بناء هذه الحلقة بسيطًا، وهو الفرق بين أتمتة تثق بها وأتمتة تجالسها.