API ریکوری ہفتہ: سخت آئیڈیمپوٹنسی کیز کے ساتھ ٹریفک بحাল کریں

غیر کنٹرول شدہ بیک لاগ ڈাম্প کا خطرہ

جب کوئی آپریشنل حادثہ آؤٹ باؤنڈ میسجنگ APIs کو فریز کر دیتا ہے، تو کلائنٹ ایپلیکیشنز لازمی طور پر سیکنڈری کیوز میں ناکام درخواستیں جمع کر لیتی ہیں۔ ان فریز کرنے کے فوراً بعد لاکھوں کیو شدہ OTP یا SMS درخواستوں کو براہ راست API پائپ لائن میں ف্লাش کرنے سے پلیٹ فارم کا سیکنڈری کریش ہو جاتا ہے۔ غیر منظم ریٹرائز سرور کا بوجھ بڑھاتے ہیں، اختتامی صارفین کو ڈپلیکیٹ ڈیلیوری کا باعث بنتے ہیں، اور ٹریفک کو کامیابی سے ڈیلیور کیے بغیر بٹوے کا بیلنس تیزی سے ختم کر دیتے ہیں۔ حقیقی آپریشنل بازیابی کے لیے خام بیک لاگ ڈمپ کے بجائے جان بوجھ کر ٹریفک شیپنگ کی ضرورت ہوتی ہے۔

ٹریفک بحالی کے دوران آئیڈیمپوٹنسی کیز کا نفاذ

لازمی آئیڈیمپوٹنسی ہیڈرز کے بغیر API گیٹ وے دوبارہ کھولنا ڈپلیکیٹ بلنگ اور کیریئر اسپیم فلیگز کی دعوت دینا ہے۔ ریکوری کے مرحلے کے دوران جمع کرایا گیا ہر ریٹرائی پेलोڈ اپنی اصل آئیڈیمپوٹنسی کی کو برقرار رکھے جو ابتدائی ڈسپیچ کے وقت تیار کی گئی تھی۔ جب کلائنٹ ایپلیکیشنز ٹریفک کو دوبارہ بھیجتی ہیں، تو ایج پلیٹ فارم یہ جانچتا ہے کہ آیا فریز سے پہلے یا اس کے دوران کی پہلے ہی پروسیس کی جا چکی ہے۔ اگر کوئی درخواست مکمل ہو چکی تھی، تو پلیٹ فارم بیلنس کٹوتی کیے بغیر یا نیا ڈسپیچ جاب جمع کرائے بغیر فوری طور پر کیش شدہ HTTP رسپانس واپس کر دیتا ہے۔

ریکوری ریٹرائی میٹرکس اور کی اسٹیٹ لائف سائیکل

ڈیٹا بیس کی گنجائش کی حفاظت کرتے ہوئے کیوز کو محفوظ طریقے سے صاف کرنے کے لیے، طے شدہ کی لائف سائیکل پیرامیٹرز کا استعمال کرتے ہوئے اپنی ریٹرائی پائپ لائن میں آئیڈیمپوٹنسی کی حالتوں کو ٹریک کریں۔

ویب ہکس اور تاخیر سے اسٹیٹس اپ ڈیٹس کا انتظام

جیسے ہی ٹریفک کا بہاؤ دوبارہ شروع ہوتا ہے، تاخیر سے ڈیلیوری رپورٹس (DLRs) اور ان باؤنڈ میسج ویب ہکس اکثر ایک ساتھ کلائنٹ کے بنیادی ڈھانچے میں سیلاب کی طرح آ جاتے ہیں۔ یقینی بنائیں کہ آپ کے ویب ہک ان جسشن اینڈ پوائنٹس آنے والے دستخطوں کی توثیق کریں اور ڈپلیکیٹ ایونٹ شناخت کنندگان کو مسترد کریں۔ ریکوری کے دوران آنے والے پेलोڈ طوفانوں کو کم کرنے کے بارے میں جامع تفصیلات کے لیے، ویب ہک دستخط اور ری پلے ونڈو میکانیزم کے بارے میں پڑھیں۔

مالیاتی حفاظتی اقدامات اور اکاؤنٹ کی حدیں

خودکار ریکوری اسکرپٹس تیزی سے بیلنس ختم کر سکتی ہیں اگر فی گھنٹہ اخراجات کی سخت حد مقرر نہ ہو۔

IOSOR کے ساتھ شروع کریں

منجمد قطار کھولیں۔ ہر پرواز میں hold کے لیے اصل Idempotency-Key محدود شرح پر دہرائیں۔ اس کنجی کے بغیر نیا POST نیا ڈیبٹ ہے — یہ بحالی نہیں۔ پھاٹک کھولنے سے پہلے تاخیری DLR اور webhook دہراؤ انہی ارادوں پر گرائیں۔

آئیڈیمپوٹنسی، دوبارہ کوشش اور پیسہ API حادثہ ہفتہ: غائب آئیڈیمپوٹنسی ایک فریز ہے، ریٹرائی طوفان نہیں.

IOSOR خلاصہ

کریں: ٹریفک کو قبول شدہ کنجیوں کے دہراؤ کے طور پر بحال کریں۔ جو حالت پہلے تصفیہ ہو چکی وہ تصفیہ رہتی ہے۔

نہ کریں: بقایا کو بالکل نئے چارجز کی طرح بنانا، یا قطار OTP ایسے بہانا جیسے واقعے نے کبھی hold ڈھالا ہی نہ ہو۔