فائدہ:
- رفتار کی حد (RPM/ITPM/OTPM) اور 429 غلطیوں کی تشریح کر سکتا ہے۔
- ایکسپونینشل بیک آف کو لاگو کرتا ہے اور دوبارہ کوشش کے بعد دوبارہ کوشش کرتا ہے۔
- عام HTTP ایرر کوڈز کو درست طریقے سے درجہ بندی اور ہینڈل کرتا ہے (400/401/429/500/529)
پیداواری ماحول میں، کوئی بھی API ہر وقت مکمل طور پر جواب نہیں دیتا۔ بعض اوقات آپ درخواستیں بہت تیزی سے بھیجتے ہیں اور حد تک پہنچ جاتے ہیں۔ بعض اوقات سرور عارضی طور پر مصروف ہوتا ہے۔ بعض اوقات آپ کی درخواست شروع سے ہی غلط ہوتی ہے۔ جو چیز ایک شوقیہ کوشش سے ٹھوس انضمام کو ممتاز کرتی ہے وہ یہ ہے کہ یہ ان حالات کو پیش گوئی اور خود بخود ہینڈل کرتا ہے۔ اس یونٹ میں آپ شرح کی حدود (RPM/ITPM/OTPM)، 429 ایرر، ایکسپونیشنل بیک آف کے ساتھ دوبارہ کوشش، اور عام HTTP ایرر کوڈز کی مناسب درجہ بندی کے بارے میں سیکھیں گے۔ مقصد: ایک ایسا بہاؤ بنانا جو اتنا مضبوط ہو کہ صارف اسے کبھی محسوس نہ کرے۔
رفتار کی حدود کیا ہیں؟
فراہم کنندہ اس بات کو محدود کرتا ہے کہ ایک مقررہ مدت میں سوئچ کتنا کام کرسکتا ہے۔ یہ تحفظ؛ یہ انفراسٹرکچر اور آپ دونوں کو اچانک ہونے والے دھماکوں سے بچاتا ہے۔ حدود کی تین عام قسمیں ہیں:
- RPM (درخواستیں فی منٹ): فی منٹ درخواستوں کی تعداد۔
- ITPM (ان پٹ ٹوکن فی منٹ): ان پٹ ٹوکن جس پر فی منٹ کارروائی کی جا سکتی ہے۔
- OTPM (آؤٹ پٹ ٹوکن فی منٹ): آؤٹ پٹ ٹوکن جو فی منٹ تیار کیا جا سکتا ہے۔
اگر آپ ان میں سے کسی بھی حد سے تجاوز کرتے ہیں، تو فراہم کنندہ درخواست کو مسترد کر دیتا ہے اور ایک 429 ایرر کوڈ واپس کرتا ہے۔ حدود عام طور پر آپ کے اکاؤنٹ کی سطح (ٹیر) کے لحاظ سے مختلف ہوتی ہیں اور وقت کے ساتھ ساتھ بڑھائی جا سکتی ہیں۔
ٹپ: آپ دیکھ سکتے ہیں جب آپ جوابی سرخیوں سے حد تک پہنچ رہے ہیں۔ زیادہ تر فراہم کنندگان آپ کے بقیہ کوٹے کی اطلاع x-ratelimit-remaining-* جیسے ہیڈر کے ساتھ دیتے ہیں۔ ان اقدار کی نگرانی کرنا اور ٹریفک کو سامنے رکھنا 429 حاصل کیے بغیر مسئلے کو روکنے کا سب سے پختہ طریقہ ہے۔
429 اور Exponential Retracement
429 (شرح کی حد) ایک عارضی اور دوبارہ قابل کوشش غلطی ہے۔ درست جواب یہ ہے کہ درخواست کا تھوڑی دیر انتظار کریں اور دوبارہ کوشش کریں۔ لیکن مسلسل انتظار کافی نہیں ہے۔ اگر سب نے ایک ہی وقت میں دوبارہ کوشش کی تو حد دوبارہ پہنچ جائے گی۔ حل ایکسپونینشل بیک آف ہے: ہر ناکام کوشش کے ساتھ انتظار کے وقت کو تیزی سے بڑھانا۔
# ایکسپونینشل بیک آف لاجک ٹرائل 1 → 429 → انتظار کریں 1 سیکنڈ ٹرائل 2 → 429 → انتظار کریں 2 سیکنڈ ٹرائل 3 → 429 → انتظار کریں 4 سیکنڈ ٹرائل 4 → 429 → انتظار کریں 8 سیکنڈ (+ چھوٹا بے ترتیب "جیٹر")... ترک کریں اور زیادہ سے زیادہ N ٹرائل کے بعد رپورٹ کریں
اس میں تھوڑا سا بے ترتیب پن (جھگڑا) شامل کرنا درخواستوں کو ٹکرانے سے روکتا ہے جب ایک ہی وقت میں دوبارہ کوشش کرنے کی کوشش کی جاتی ہے۔ مزید برآں، 429 جواب میں اکثر 'دوبارہ کوشش کے بعد' ہیڈر ہوتا ہے: "اس کئی سیکنڈ میں دوبارہ کوشش کریں"۔ اس عنوان کا احترام کرنا آنکھیں بند کر کے انتظار کرنے سے زیادہ درست ہے۔
احتیاط: جب آپ کو 429 ملتا ہے، "مزید درخواستیں بھیج کر اسے مجبور کرنا" صورتحال کو مزید خراب کر دے گا۔ حد کو پُر کرنا جاری ہے اور کوئی درخواست نہیں گزرتی ہے۔ درست جواب اعتکاف ہے، سرعت نہیں۔ اچھی خبر: زیادہ تر سرکاری SDKs خود بخود بیک آف کے ساتھ 429 اور سرور کی خرابیوں کی دوبارہ کوشش کرتے ہیں — SDK کے اس طرز عمل کو دستی طور پر انسٹال کرنے سے پہلے استعمال کریں۔
HTTP ایرر کوڈز کی درجہ بندی کرنا
ہر غلطی ایک جیسی نہیں ہوتی۔ اہم امتیاز: کیا اس کی دوبارہ کوشش کی جا سکتی ہے یا یہ درخواست/شناخت کا مسئلہ ہے؟
کوڈ
مطلب
کیا اسے دوبارہ آزمایا جا سکتا ہے؟
درست جواب
400
غلط درخواست (فارمیٹ/پیرامیٹر کی خرابی)
نہیں
درخواست درست کریں؛ دوبارہ نہ بھیجیں۔
401
تصدیق کی خرابی (کلید غلط/لاپتہ)
نہیں
کلید/عنوان درست کریں۔
403
کوئی اجازت نہیں (ماڈل/فیچر تک رسائی نہیں)
نہیں
اجازتیں/اسکوپ چیک کریں۔
404
نہیں ملا (غلط ماڈل ID/اینڈ پوائنٹ)
نہیں
درست ماڈل ID/پتہ
429
رفتار کی حد سے تجاوز کر گیا۔
جی ہاں
پیچھے ہٹنا + دوبارہ کوشش کرنے کے بعد
500
سرور کی خرابی۔
جی ہاں
اعتکاف کے ساتھ دوبارہ کوشش کریں۔
529
سرور اوور لوڈ ہو گیا۔
جی ہاں
اعتکاف کے ساتھ دوبارہ کوشش کریں۔
سنہری اصول: 429، 500 اور 529 عارضی ہیں؛ واپسی کے ساتھ دوبارہ کوشش کی جاتی ہے۔ 400, 401, 403, 404 درخواست/شناخت کے مسائل ہیں۔ دوبارہ کوشش کرنے سے یہ حل نہیں ہوگا، اور یہ کوشش ضائع کرتا ہے۔ آپ کے کوڈ کو ان دو گروپوں کے درمیان فرق کرنا چاہیے۔
مرحلہ وار: پائیدار کال
- درخواست جمع کروائیں۔ اگر کامیاب رہے تو جاری رکھیں۔
- غلطی کوڈ کی درجہ بندی کریں۔ کیا اسے دوبارہ آزمایا جا سکتا ہے؟
- اگر کوشش کی جا سکتی ہے: دوبارہ کوشش کے بعد کی پیروی کریں، ایکسپونینشل بیک آف + جٹر لگائیں، محدود تعداد میں کوشش کریں (مثلاً 5 زیادہ سے زیادہ)۔
- اگر کوشش نہیں کی گئی تو: درست کریں (فارمیٹ/کلید) اور روکیں؛ لوپ میں ایک ہی غلط درخواست کو نہ دہرائیں۔
- ترک کرنے پر غور کریں۔ اگر n کوششوں کے بعد بھی ناکام رہے تو، صارف کو ایک شائستہ پیغام دکھائیں اور ایونٹ کو لاگ کریں (ٹریکنگ یونٹ 11)۔
# مضبوط کال pseudo-codedene = 0repeat: response = request_at() if response.success: جواب واپس کریں if response.code [429, 500, 529] میں اور کوشش کریں <5: wait = retry_after ?? (2^کوشش سیکنڈ + گھماؤ) نیند (انتظار)؛ کوشش کریں += 1؛ git again if response.code in [400, 401, 403, 404]: save_error(response)؛ واپسی "درخواست کو درست کرنا ضروری ہے" واپسی "مستقل غلطی، بعد میں کوشش کریں"
# صارف کے لیے شائستہ تاثرات (جب دوبارہ کوششیں ختم ہو جائیں) "میں ابھی مصروف ہوں، میں آپ کی درخواست پر کارروائی نہیں کر سکا۔ جلد دوبارہ کوشش کریں، یا میں نے آپ کی درخواست محفوظ کر لی ہے، جب یہ تیار ہو جائے گی تو میں آپ سے رابطہ کروں گا۔"
کمزور فوری / مضبوط اشارہ (یہاں: غلطی کا پیغام ڈیزائن)
# کمزور (صارف کو خام غلطی دکھاتا ہے)"خرابی 429: شرح_حد_غلطی"
# مضبوط (صارف دوستانہ، یقین دلانے والا، عمل کا مشورہ دینے والا) "نظام میں عارضی بھیڑ تھی۔ ہمیں آپ کی درخواست بحفاظت موصول ہو گئی ہے اور اسے خود بخود دوبارہ کرنے کی کوشش کی جا رہی ہے۔ اگر نتیجہ چند سیکنڈ میں ظاہر نہیں ہوتا ہے، تو آپ صفحہ کو ریفریش کر سکتے ہیں۔"
خام تکنیکی خرابی کو آخری صارف کے سامنے ظاہر کرنا اعتماد کو مجروح کرتا ہے اور سیکیورٹی کا خطرہ ہو سکتا ہے۔ اندرونی طور پر غلطیوں کی درجہ بندی کریں اور صارف کو ایک پرسکون، عمل پر مبنی پیغام دیں۔ ریکارڈ کے لیے صرف تکنیکی تفصیل لکھیں۔
تین چھوٹے کیسز
کیس 1 - ٹریفک دھماکے میں کشتی ٹکرا گئی۔ ایک کسٹمر سروس بوٹ کو مہم کے دن بڑھتے ہوئے ٹریفک میں 429 موصول ہوئے۔ کوڈ میں دوبارہ کوشش نہیں کی گئی، ہر خامی براہ راست صارف کو "خرابی" کے طور پر ظاہر ہوتی تھی۔ انہوں نے exponential retracement + retry-after شامل کیا۔ اسی ٹریفک کے ساتھ، درخواستیں کئی سیکنڈ کی تاخیر کے ساتھ منظور ہوئیں، صارف کو کوئی خرابی نظر نہیں آئی۔
کیس 2 - لوپ میں 400 کو آزمانا۔ ایک غلط ماڈل ID کی وجہ سے ایک انضمام کو 404 مل رہا تھا، لیکن وہ تمام غلطیوں کو "عارضی" سمجھ رہا تھا اور لامحدود لوپ میں دوبارہ کوشش کر رہا تھا۔ لاگ سوجن ہو گئی اور غیر ضروری بوجھ پیدا ہو گیا۔ انہوں نے غلطی کی درجہ بندی شامل کی: 404 کو مستقل سمجھا جاتا ہے، لوپ کو روک دیا جاتا ہے اور ماڈل ID کو درست کیا جاتا ہے۔ سبق: ہر غلطی کو دوبارہ نہ کرنے کی کوشش کریں۔
کیس 3 - سامنے سے حد کا انتظام کرنا۔ ڈیٹا کی افزودگی کا کام مسلسل 429 کی حد پر چل رہا تھا۔ انہوں نے x-ratelimit-بقیہ ہیڈر کی پیروی کی اور ٹریفک کو کوٹے کے مطابق روک دیا۔ لہذا انہوں نے بغیر کسی 429s کے، حد سے بالکل نیچے ایک مستحکم رفتار رکھی۔ کام زیادہ پیش گوئی اور تیزی سے کیا گیا تھا۔
عام غلطیاں
- 429 میں رفتار میں اضافہ: صورتحال کو مزید خراب کرتا ہے۔ اعتکاف پر سوئچ کریں۔
- ہر غلطی کی دوبارہ کوشش کرنا: 400/401/404 مستقل ہے؛ دوبارہ کوشش کرنا بربادی ہے۔
- مقررہ انتظار کا استعمال کرتے ہوئے: تصادم پیدا کرتا ہے۔ ایکسپونینشل + جٹر استعمال کریں۔
- 'دوبارہ کوشش کے بعد' کو نظر انداز کرنا: فراہم کنندہ کے بتائے ہوئے وقت کی تعمیل کرنا انتہائی درست ہے۔
- صارف کے سامنے خام غلطی کا انکشاف: اعتماد کو متزلزل کرتا ہے، کمزوریاں پیدا کرتا ہے۔ اندر کی درجہ بندی کریں۔
- لامحدود دوبارہ کوششیں: ایک بالائی حد مقرر کریں (مثال کے طور پر 5 دوبارہ کوششیں)؛ پھر نرمی سے چھوڑ دو.
گہرا: قطار لگانا، کنکرنسی، اور سرکٹ بریکر
ایک خواہش کی برداشت پہلا قدم ہے۔ اصل پختگی یہ ہے کہ حد سے گزرے بغیر بڑی تعداد میں درخواستوں کا انتظام کیا جائے۔ یہاں تین تصورات کام آتے ہیں۔
قطار: آپ درخواستوں کو ایک قطار میں لگاتے ہیں تاکہ انہیں فوری طور پر بجائے ایک کنٹرول رفتار سے بھیجیں۔ قطار لگانا ٹریفک کے اچانک پھٹنے کو ہموار کرتا ہے: یہاں تک کہ اگر 1,000 درخواستیں ایک ساتھ آتی ہیں، تو قطار انہیں حد سے کم شرح پر جاری کرے گی۔ اس طرح آپ 429 کو روکتے ہیں، پھر آپ کو اسے ٹھیک کرنے کے بارے میں فکر کرنے کی ضرورت نہیں ہے۔
ہم آہنگی کی حد: آپ اس بات کو محدود کرتے ہیں کہ ایک ہی وقت میں "ہوا میں" کتنی درخواستیں ہیں۔ لامحدود متوازی درخواستیں تیزی سے RPM اور TPM کی حدود کو پُر کرتی ہیں۔ ایک مناسب ہم آہنگی کی حد (مثلاً 10 سے زیادہ ہم آہنگی کی درخواستیں) دونوں ہی حدود کو برقرار رکھتی ہیں اور نظام کو قابل قیاس بناتی ہیں۔
سرکٹ بریکر: اگر فراہم کنندہ 500/529 واپس کرتا رہتا ہے، بجائے اس کے کہ ہر درخواست کو سختی سے آزمائیں، تو آپ تھوڑی دیر کے لیے "سرکٹ کو توڑ دیں" اور درخواست بھیجے بغیر جلدی سے ناکام ہوجاتے ہیں۔ ایک انتظار کے بعد، آپ سرکٹ کو دوبارہ آن کریں اور کوشش کریں۔ یہ پیٹرن آپ کے سسٹم کو عارضی فراہم کنندہ کی ناکامی کی صورت میں کریش ہونے سے روکتا ہے۔
یہ تینوں مل کر ایک کال کی دوبارہ کوشش کی منطق سے آگے نظام کی سطح پر لچک پیدا کرتے ہیں۔ چھوٹے پیمانے پر، SDK کی خودکار دوبارہ کوشش کافی ہے۔ جیسے جیسے پیمانہ بڑھتا ہے، قطار لگانا، کنکرنسی، اور سرکٹ بریکر ناگزیر ہو جاتے ہیں۔ ان سب کا ایک ہی مقصد ہے: صارف کے لیے کسی عارضی مسئلے کی عکاسی کریش کے طور پر نہیں، بلکہ چند سیکنڈ کی غیر مرئی تاخیر کے طور پر کرنا۔
خلاصہ میں
رفتار کی حد (RPM/ITPM/OTPM) سے تجاوز کرنے پر 429 واپسی؛ یہ ایک عارضی خرابی ہے اور دوبارہ کوشش کے بعد اور ایکسپونینشل بیک آف + جٹر کا استعمال کرکے دوبارہ کوشش کی جائے گی۔ 500 اور 529 بھی عارضی ہیں۔ 400/401/403/404 ایک درخواست/شناخت کا مسئلہ ہے اور اسے دوبارہ کوشش کر کے حل نہیں کیا جا سکتا۔ ایک مضبوط بہاؤ ان دو گروہوں میں غلطیوں کو الگ کرتا ہے، محدود تعداد میں کوشش کرتا ہے، سامنے سے حد کی نگرانی کرتا ہے اور صارف کو پرسکون پیغامات دکھاتا ہے۔
درخواست کا کام
اپنے انضمام پر غور کریں۔ (1) ان ایرر کوڈز کی فہرست بنائیں جن کا آپ سامنا کر سکتے ہیں اور انہیں "دوبارہ کوشش/مستقل" میں الگ کریں۔ (2) اپنا ایکسپونینشل پل بیک پلان لکھیں (ابتدائی ہولڈ، گتانک، کیپ، جٹر)۔ (3) وضاحت کریں کہ دوبارہ کوشش کے بعد ہیڈر کو کیسے استعمال کیا جائے۔ (4) دوبارہ کوششیں ختم ہونے پر صارف کو دکھائے جانے والا شائستہ پیغام لکھیں۔
چیک لسٹ
- میں RPM/ITPM/OTPM حدود اور 429 کی وضاحت کر سکتا ہوں۔
- [ ] میں exponential retreat + jitter + retry-after کی منطق کا اطلاق کر سکتا ہوں۔
- میں ایرر کوڈز کو دوبارہ قابل کوشش/مستقل کے طور پر درجہ بندی کر سکتا ہوں۔
- میں جانتا ہوں کہ ہمیں ہر غلطی کی کوشش نہیں کرنی چاہیے۔
- خام غلطی کے بجائے، میں صارف کو ایک پرسکون، عمل پر مبنی پیغام دکھا سکتا ہوں۔