ہم اپنی ہی سروسز کو rate limit کر رہے تھے

Mythex کی API ایک network address سے فی منٹ 300 درخواستوں کی اجازت دیتی ہے۔ یہ حد اس لیے ہے کہ کوئی ایک شخص یا script API پر حملہ نہ کرے۔ Production میں اس نے اس کے بجائے ہماری اپنی سروسز کو روکنا شروع کر دیا، یعنی ہمارے edge کا وہ حصہ جو published ایپس دیتا ہے اور وہ سروس جو AI agent چلاتی ہے، کیونکہ ان میں سے ہر ایک API تک صرف چند پتوں سے پہنچتا ہے۔ جو درخواستیں ہمارا اندرونی credential رکھتی ہیں اب انہیں استثنا حاصل ہے، اور باقی سب پر پہلے کی طرح حد لاگو ہے۔

علامت

API نے ہماری اپنی کچھ اندرونی کالز کو 429 Too Many Requests کے ساتھ جواب دینا شروع کر دیا۔ تین قسم کی کالز متاثر ہوئیں، اور ان میں سے ہر ایک Mythex استعمال کرنے والے کسی نہ کسی شخص کے لیے اہم ہے:

یہ دیکھنا کہ کسی custom domain پر کون سی ایپ ہے۔ جب visitor اپنے domain پر کوئی published ایپ کھولتا ہے تو ہمارا edge API سے پوچھتا ہے کہ وہ سائٹ کہاں ہے۔ وہاں 429 کا مطلب ہے کہ visitor کسی سائٹ تک نہیں پہنچ سکتا۔
چلتے ہوئے agent turn کو محفوظ کرنا۔ جب agent کام کرتا ہے تو اس کی پیش رفت ساتھ ساتھ محفوظ ہوتی ہے، تاکہ refresh یا ٹوٹے ہوئے کنکشن کے بعد بھی جواب باقی رہے۔ وہاں 429 کا مطلب ہے کہ پیش رفت محفوظ نہیں ہوئی۔
preview تک رسائی کی جانچ۔ جس ایپ کو آپ بنا رہے ہیں اس کا preview محدود ہے، اور وہ پابندی API سے پوچھتی ہے۔ وہاں 429 کا مطلب ہے کہ preview نہیں کھلے گا۔

ان میں سے کوئی بھی کال کسی انسان نے API کو نہیں کی تھی۔ سب ہماری طرف سے تھیں۔

یہ کیوں ہوا

فی پتہ rate limit ایک مفروضے پر کھڑی ہے: ایک پتہ تقریباً ایک caller ہے۔ انسانوں کے لیے یہ کافی قریب ہے۔ ہمارے اپنے infrastructure کے لیے یہ بری طرح غلط ہے۔

وہ edge سروس جو published ایپس اور previews دیتی ہے، API تک چند مشترکہ outgoing پتوں سے پہنچتی ہے۔ ہر published ایپ کے ہر visitor اور ہر preview کی جانچ ان چند میں سے کسی ایک کی طرف سے آئی ہوئی لگتی ہے۔
Orchestrator، یعنی وہ سروس جو agent turns چلاتی ہے، API تک ایک container کے پتے سے پہنچتی ہے۔ ہر چلتا ہوا turn، ہر صارف کا، اسی کو بانٹتا ہے۔

یوں ایک شخص کے لیے بنایا گیا بجٹ پوری سروس کے تمام ٹریفک میں بٹ رہا تھا۔ وہ سروسز آپس میں اسے ختم کر دیتی تھیں، اور limiter نے وہی کیا جو اسے کہا گیا تھا: اس نے انہیں روک دیا۔

حل

ہماری اپنی سروسز پہلے ہی ثابت کرتی ہیں کہ وہ کون ہیں۔ ہر اندرونی کال ایک اندرونی token لے کر جاتی ہے، اور API کے اندرونی حصے کا ہر route کچھ کرنے سے پہلے وہ token جانچتا ہے۔

Rate limiter اب وہی جانچ استعمال کرتا ہے۔ جس درخواست کا token اندرونی token سے ملتا ہے وہ ایک allow list پر ہے اور فی پتہ بجٹ میں شمار نہیں ہوتی۔ باقی سب پہلے کی طرح شمار ہوتا ہے: فی پتہ فی منٹ 300 درخواستیں۔

دو تفصیلات نے اسے ایک سوراخ بننے سے روکا:

غلط token کو کوئی استثنا نہیں ملتا۔ Allow list صرف اصل اندرونی token سے ملتی ہے۔ من گھڑت token والی درخواست باقی کی طرح شمار اور throttle ہوتی ہے، اور اندرونی routes اسے پھر بھی 401 Unauthorized کے ساتھ رد کرتے ہیں۔
خود حد نہیں بدلی۔ ہم نے جگہ بنانے کے لیے عدد نہیں بڑھایا۔ عدد بڑھانے سے مسئلہ ٹریفک دوبارہ بڑھنے تک چھپ جاتا، اور جس صورت کے لیے حد ہے اس کے خلاف تحفظ کمزور ہو جاتا۔

ہم نے limiter کی settings ایک چھوٹے function میں رکھیں اور اس پر tests لکھے۔ ایک test اندرونی token کے ساتھ 20 درخواستیں ایک ایسے limiter کو بھیجتا ہے جو 5 کی اجازت دیتا ہے، اور توقع رکھتا ہے کہ 20 کی 20 کامیاب ہوں۔ ایک دوسرا test ایک پتے سے عام درخواستیں بھیجتا ہے اور توقع رکھتا ہے کہ پہلی پانچ کامیاب ہوں اور بعد والی رد ہوں۔ تیسرا جعلی token والی درخواستیں بھیجتا ہے اور توقع رکھتا ہے کہ وہ اسی طرح رد ہوں۔

ہم نے اس سے کیا سیکھا

حدیں مفروضے رکھتی ہیں۔ “ایک پتہ، ایک caller” فی پتہ حد میں بنا ہوا ہے۔ یہ اس لمحے سچ نہیں رہتا جب آپ کی اپنی سروسز مشترکہ پتوں کے پیچھے ہوں، اور بہت سی ایسی ہوتی ہیں: load balancers، edge networks، containers، دفتری نیٹ ورک۔
اپنا ٹریفک شناخت سے پہچانیں، پتے سے نہیں۔ پتے یہ بتاتے ہیں کہ ٹریفک کیسے پہنچا، یہ نہیں کہ اسے کس نے بھیجا۔ ہمارے پاس پہلے سے ایک credential تھا جو ثابت کرتا تھا کہ کال ہماری ہے؛ limiter بس اس کی طرف دیکھ نہیں رہا تھا۔
عدد بڑھا کر ٹھیک نہ کریں۔ بڑی حد 429 کو کچھ دیر کے لیے غائب کر دیتی، کم تحفظ دیتی، اور بعد میں پھر ناکام ہوتی۔
دیکھیں کہ کس کو throttle ہو رہا ہے۔ آپ کی اپنی سروس پر آنے والا 429 آپ کی حدوں کے بارے میں ایک bug report ہے، یہ اس بات کی علامت نہیں کہ limiter ٹھیک کام کر رہا ہے۔

اگر آپ Mythex پر بناتے ہیں تو اس کا کیا مطلب ہے

آپ کی طرف کچھ بدلنے کی ضرورت نہیں۔ Custom domains پر published ایپس، agent turns اور previews اب اس پر منحصر نہیں کہ Mythex کا باقی حصہ کتنا مصروف ہے۔ آپ کی ایپ کا اپنا ٹریفک آپ کی ایپ کا معاملہ ہے: یہاں بیان کی گئی حد ہماری API پر ہے، نہ کہ آپ کی published ایپس پر۔

اگر آپ اپنا backend چلاتے ہیں تو یہی جال کسی بھی rate limit پر لاگو ہوتا ہے جو آپ شامل کریں۔ شروع کرنے کے لیے API کیا ہے اور AI سے بنی ایپس کے لیے سیکیورٹی چیک لسٹ اچھی جگہیں ہیں۔ اور ہمارے اپنے infrastructure کے اپنے ہی راستے میں آنے کی ایک اور مثال کے لیے دیکھیں ہم نے deploys کو صفر 502 errors تک کیسے پہنچایا۔