API کارکردگی: شرح کی حد بندی، صفحہ بندی اور Async پروسیسنگ

آپ کا API اتنا ہی تیز ہے جتنا کہ چوٹی کے بوجھ کے تحت اس کا سب سے سست اینڈ پوائنٹ۔ ایک واحد غیر آپٹمائزڈ اینڈ پوائنٹ جو ڈیٹا بیس کنکشنز کو 5 سیکنڈ تک رکھتا ہے آپ کے پورے پلیٹ فارم میں آپ کے کنکشن پول اور جھرنے کی ناکامیوں کو ختم کر سکتا ہے۔ API کارکردگی انجینئرنگ تین ستونوں پر مرکوز ہے: آپ کے API کو اوورلوڈ سے بچانا (ریٹ محدود کرنا)، بڑے ڈیٹا سیٹس کو موثر طریقے سے ہینڈل کرنا (صفحہ بندی)، اور مہنگے آپریشنز کو درخواست کے چکر سے باہر منتقل کرنا (async پروسیسنگ)۔

اہم ٹیک ویز

• ٹوکن بالٹی اور سلائیڈنگ ونڈو دو شرح کو محدود کرنے والے الگورتھم ہیں جو استعمال کے 95% کیسز کا احاطہ کرتے ہیں -- اس بنیاد پر انتخاب کریں کہ آیا آپ برسٹ ٹولرنس چاہتے ہیں یا سخت نفاذ
• کرسر پر مبنی صفحہ بندی بڑے ڈیٹاسیٹس کے لیے آفسیٹ صفحہ بندی کو بہتر کرتی ہے کیونکہ یہ چھوڑی ہوئی قطاروں کو گننے سے گریز کرتا ہے۔
• جاب کی قطاروں کے ساتھ Async پروسیسنگ ای میل بھیجنے، پی ڈی ایف جنریشن، اور ویب ہک کی ترسیل کو درخواست کے راستے سے ہٹا کر P95 کے جوابی اوقات کو کم کرتی ہے۔
• Brotli کے ساتھ رسپانس کمپریشن پے لوڈ کے سائز کو 70-85% تک کم کرتا ہے، جو براہ راست کلائنٹ کی طرف تیز تر رینڈرنگ میں ترجمہ کرتا ہے۔

---

شرح کو محدود کرنے والے الگورتھم

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

ٹوکن بالٹی

ٹوکن بالٹی الگورتھم زیادہ تر APIs کے لیے سب سے زیادہ عملی انتخاب ہے۔ ایک بالٹی زیادہ سے زیادہ صلاحیت تک ٹوکن رکھتی ہے۔ ٹوکن ایک مقررہ شرح (دوبارہ بھرنے کی شرح) پر شامل کیے جاتے ہیں۔ ہر درخواست میں ایک ٹوکن استعمال ہوتا ہے۔ اگر بالٹی خالی ہے تو درخواست مسترد یا قطار میں لگ جاتی ہے۔

ٹوکن بالٹی کا اہم فائدہ برسٹ ٹولرنس ہے۔ اگر کسی کلائنٹ نے تھوڑی دیر کے لیے درخواستیں نہیں کی ہیں، تو اس کی بالٹی بھری ہوئی ہے اور وہ بالٹی کی گنجائش تک درخواستیں دے سکتے ہیں۔ یہ قدرتی استعمال کے نمونوں سے میل کھاتا ہے -- ایک کلائنٹ جو ڈیش بورڈ کو لوڈ کرتا ہے وہ تیزی سے یکے بعد دیگرے 20 درخواستیں کرسکتا ہے، پھر 30 سیکنڈ تک کچھ نہیں۔

ایک ای کامرس API کے لیے ترتیب کی مثال:

• بالٹی کا سائز: 100 ٹوکن
• ری فل کی شرح: 10 ٹوکن فی سیکنڈ
• یہ فی سیکنڈ طویل مدتی 10 درخواستوں کو برقرار رکھتے ہوئے 100 درخواستوں کو پھٹنے کی اجازت دیتا ہے۔

سلائیڈنگ ونڈو کاؤنٹر

سلائیڈنگ ونڈو کاؤنٹر سلائیڈنگ ونڈو لاگ کی درستگی کو فکسڈ ونڈو کی میموری کی کارکردگی کے ساتھ جوڑتا ہے۔ یہ موجودہ اور پچھلی ونڈو کے کاؤنٹرز کو برقرار رکھتا ہے، پھر موجودہ ونڈو میں درخواست کتنی دور تک آتی ہے اس کی بنیاد پر وزنی گنتی کا حساب لگاتا ہے۔

60 سیکنڈ کی ونڈو کے لیے جس کا اندازہ 45 سیکنڈ میں ہوتا ہے، مؤثر شمار یہ ہے: (پچھلی ونڈو کی گنتی * 0.25) + (موجودہ ونڈو کی گنتی)۔ یہ انفرادی درخواست کے ٹائم اسٹیمپ کو ذخیرہ کیے بغیر فکسڈ ونڈوز کے باؤنڈری برسٹ کے مسئلے کو ختم کرتا ہے۔

Redis کے ساتھ عمل درآمد

Redis تقسیم شدہ شرح کو محدود کرنے کے لیے ایک معیاری بیکنگ اسٹور ہے کیونکہ یہ TTL کے ساتھ ایٹم انکریمنٹ آپریشن فراہم کرتا ہے۔ فکسڈ ونڈوز کے لیے EXPIRE کے ساتھ INCR استعمال کریں، یا سلائیڈنگ ونڈوز کے لیے ZADD اور ZRANGEBYSCORE کے ساتھ ترتیب شدہ سیٹ استعمال کریں۔ ٹوکن بالٹی کے لیے، Redis Lua اسکرپٹس ایٹم چیک اینڈ ڈیکرمنٹ آپریشنز فراہم کرتی ہیں۔

درجہ محدود کرنے والے ہیڈر API صارفین کو حدیں بتائیں:

• X-RateLimit-Limit -- ونڈو میں زیادہ سے زیادہ درخواستوں کی اجازت ہے۔
• X-RateLimit-Remaining -- درخواستیں موجودہ ونڈو میں باقی ہیں۔
• X-RateLimit-Reset -- ونڈو ری سیٹ ہونے پر یونکس ٹائم اسٹیمپ
• Retry-After -- سیکنڈ تک جب تک کہ کلائنٹ دوبارہ کوشش نہ کرے (429 جوابات پر)

---

صفحہ بندی کی حکمت عملی

ہر فہرست کا اختتامی نقطہ صفحہ بندی ہونا چاہیے۔ بے حد نتیجہ واپس آنا بینڈوڈتھ کو ضائع کرتا ہے، ڈیٹا بیس کو دباتا ہے، اور ڈیٹا کے بڑھنے کے ساتھ ساتھ ٹائم آؤٹ کی غلطیوں کا خطرہ ہوتا ہے۔

صفحہ بندی آفسیٹ

آفسیٹ صفحہ بندی LIMIT اور OFFSET SQL شقوں کا استعمال کرتی ہے۔ کلائنٹ ?page=3&limit=20 کی درخواست کرتا ہے، اور سرور OFFSET 40 LIMIT 20 میں ترجمہ کرتا ہے۔

فائدے:

• لاگو کرنے اور سمجھنے میں آسان
• کلائنٹ براہ راست کسی بھی صفحے پر جاسکتے ہیں۔
• کل گنتی "Y کا صفحہ X" UI کو فعال کرتی ہے۔

نقصانات:

• اعلی آفسیٹس کے ساتھ کارکردگی میں کمی آتی ہے -- OFFSET 1000000 اب بھی نتائج واپس کرنے سے پہلے 1,000,000 قطاروں کو اسکین کرتا ہے
• صفحات کے درمیان ڈیٹا تبدیل ہونے پر متضاد نتائج (نئے ڈیٹا کے داخل یا حذف ہونے پر قطاریں بدل جاتی ہیں)
• کُل گنتی کا سوال (COUNT(*)) بڑی میزوں پر مہنگا ہو سکتا ہے۔

کرسر پر مبنی صفحہ بندی

کرسر پر مبنی صفحہ بندی نتیجہ کے سیٹ میں پوزیشن کو نشان زد کرنے کے لیے ایک مبہم کرسر (عام طور پر ایک انکوڈ شدہ بنیادی کلید یا ٹائم اسٹیمپ) کا استعمال کرتی ہے۔ کلائنٹ ?cursor=abc123&limit=20 کی درخواست کرتا ہے، اور سرور کرسر کو WHERE شق کے طور پر استعمال کرتا ہے: WHERE id > decoded(abc123) LIMIT 20۔

فائدے:

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

نقصانات:

• صوابدیدی صفحات پر نہیں جا سکتے ("صفحہ 50 پر جائیں" نہیں)
• لاگو کرنے کے لیے زیادہ پیچیدہ، خاص طور پر ملٹی کالم ترتیب کے آرڈرز کے ساتھ
• اگر ضرورت ہو تو کل گنتی الگ سے فراہم کی جائے۔

کون سا صفحہ بندی استعمال کرنا ہے۔

صفحہ بندی رسپانس فارمیٹ

ایک اچھی طرح سے ڈیزائن کردہ صفحہ بندی کے جواب میں میٹا ڈیٹا شامل ہے جسے کلائنٹس کو نیویگیٹ کرنے کی ضرورت ہے:

{
  "data": [],
  "pagination": {
    "total": 15432,
    "limit": 20,
    "hasMore": true,
    "nextCursor": "eyJpZCI6MTAwfQ=="
  }
}

---

کام کی قطاروں کے ساتھ Async پروسیسنگ

مطابقت پذیر API اینڈ پوائنٹس کو 200ms کے اندر جوابات واپس کرنے چاہئیں۔ کوئی بھی آپریشن جس میں زیادہ وقت لگتا ہے -- ای میلز بھیجنا، پی ڈی ایف تیار کرنا، تصاویر پر کارروائی کرنا، بیرونی APIs کو کال کرنا، رپورٹس چلانا -- کو بیک گراؤنڈ جاب کی قطار میں منتقل کیا جانا چاہیے۔

ملازمت کی قطار کا پیٹرن

1. API کا اختتامی نقطہ درخواست کی توثیق کرتا ہے اور نوکری کا ریکارڈ بناتا ہے۔
2. نوکری ایک قطار میں رکھی گئی ہے (Redis, RabbitMQ, SQS)
3. API 202 قبول شدہ جواب اور نوکری کی شناخت کے ساتھ فوری طور پر واپس آتا ہے۔
4. ایک کارکن کا عمل کام کو اٹھاتا ہے اور اسے غیر مطابقت پذیر طریقے سے انجام دیتا ہے۔
5. کلائنٹ نوکری کی حیثیت کے لیے پول کرتا ہے یا مکمل ہونے پر ویب ہک کال بیک وصول کرتا ہے۔

کامن Async استعمال کے کیسز

ای میل بھیجنا -- فراہم کنندہ کے لحاظ سے SMTP آپریشنز میں 500ms-3s لگتے ہیں۔ ای میلز کو قطار میں کھڑا کرنے سے API کا جوابی وقت کم ہو جاتا ہے اور صارف کو بلاک کیے بغیر عارضی ناکامیوں کے لیے منطق کو دوبارہ آزمانے کی اجازت دیتا ہے۔

پی ڈی ایف جنریشن -- رسیدیں، رپورٹیں، یا فائلیں برآمد کرنا CPU-انتہائی اور میموری پر بھاری ہے۔ ان کو سرشار کارکنوں میں چلانا API کی درخواست کو سنبھالنے کے ساتھ وسائل کے تنازعہ کو روکتا ہے۔

ویب ہُک ڈیلیوری -- آؤٹ گوئنگ ویب ہکس تھرڈ پارٹی سرور کی دستیابی پر منحصر ہے۔ اپنے سسٹم کو بلاک کیے بغیر عارضی ناکامیوں کو سنبھالنے کے لیے ایکسپونینشل بیک آف دوبارہ کوشش (1s، 2s، 4s، 8s، 5 منٹ تک) کے ساتھ قطار میں ویب ہک ڈیلیوری کریں۔

ڈیٹا درآمد اور برآمد -- 100,000 قطاروں کے ساتھ CSV اپ لوڈز پر کارروائی کبھی بھی درخواست کے چکر میں نہیں ہونی چاہیے۔ اپ لوڈ کو قبول کریں، نوکری کی شناخت واپس کریں، اور قطاروں کو بیچوں میں پروسیس کریں۔

قطار کا انتخاب

---

رسپانس آپٹیمائزیشن

درخواست کی منطق سے ہٹ کر، ردعمل کو خود سائز اور ترسیل کی رفتار کے لیے بہتر بنایا جا سکتا ہے۔

کمپریشن

نیٹ ورک پر پے لوڈ کے سائز کو کم کرنے کے لیے رسپانس کمپریشن کو فعال کریں۔ جدید کمپریشن الگورتھم ٹیکسٹ پر مبنی پے لوڈز (JSON، HTML، CSS، JavaScript) کو نمایاں طور پر کم کرتے ہیں۔

جامد اثاثوں کے لیے بروٹلی کا استعمال کریں (تعمیر وقت پر پہلے سے کمپریسڈ) اور gzip کو متحرک ردعمل کے لیے فال بیک کے طور پر استعمال کریں۔ NestJS میں، کمپریشن مڈل ویئر اسے خود بخود ہینڈل کرتا ہے، لیکن پیداوار میں، Nginx کو اپنے ایپلیکیشن سرور سے CPU کو آف لوڈ کرنے کے لیے کمپریشن کو ہینڈل کرنے دیں۔

فیلڈ کا انتخاب

API صارفین کو صرف ان فیلڈز کی درخواست کرنے کی اجازت دیں جن کی انہیں ضرورت ہے۔ GraphQL یہ فطری طور پر کرتا ہے، لیکن REST APIs ?fields=id,name,price استفسار پیرامیٹر کے ساتھ فیلڈ سلیکشن کی حمایت کر سکتے ہیں۔ اس سے پے لوڈ کا سائز کم ہو جاتا ہے اور صرف مطلوبہ کالموں کو منتخب کر کے ڈیٹا بیس کے سوالات کو بہتر بنایا جا سکتا ہے۔

رسپانس کیشنگ ہیڈرز

API کے جوابات پر مناسب Cache-Control ہیڈر سیٹ کریں۔ عوامی فہرست کے اختتامی پوائنٹس (مصنوعات، زمرے) Cache-Control: public, max-age=300 کو 5 منٹ تک کیش کرنے کے لیے استعمال کر سکتے ہیں۔ توثیق شدہ اینڈ پوائنٹس کو CDN کیشنگ کو روکنے کے لیے Cache-Control: private, no-cache استعمال کرنا چاہیے جبکہ براؤزر کیچنگ کو دوبارہ توثیق کے ساتھ اجازت دی جائے۔

کیشنگ کی حکمت عملیوں کے بارے میں مزید جاننے کے لیے، Redis, CDN، اور HTTP کیشنگ پر ہماری تفصیلی گائیڈ دیکھیں۔

---

کنکشن مینجمنٹ

ڈیٹا بیس اور HTTP کنکشن محدود وسائل ہیں جن کو بوجھ کے تحت احتیاط سے منظم کیا جانا چاہیے۔

ڈیٹا بیس کنکشن پولنگ

کنکشن پول دوبارہ قابل استعمال ڈیٹا بیس کنکشن کا ایک سیٹ برقرار رکھتا ہے۔ پولنگ کے بغیر، ہر API کی درخواست ایک نیا ڈیٹا بیس کنکشن کھولتی ہے (50-100ms اوور ہیڈ) اور جواب کے بعد اسے بند کر دیتی ہے۔ پولنگ کے ساتھ، پول سے کنکشن ادھار لینے کی درخواست کرتا ہے اور مکمل ہونے پر انہیں واپس کرتا ہے۔

پول سائز سازی کا فارمولا: کنکشنز = (کور_کاؤنٹ * 2) + موثر_اسپنڈل_کاؤنٹ۔ SSD اسٹوریج والے 4 کور سرور کے لیے، فی ایپلیکیشن مثال کے طور پر 10-20 کنکشن ایک اچھا نقطہ آغاز ہے۔ پول کے استعمال کی نگرانی کریں -- اگر یہ باقاعدگی سے 80% سے زیادہ ہے، یا تو پول کا سائز بڑھائیں یا استفسار کی مدت کو بہتر بنائیں۔

HTTP زندہ رکھیں

اپ اسٹریم سروسز (ڈیٹا بیسز، ریڈیس، بیرونی APIs) کے کنکشنز کے لیے HTTP کو زندہ رکھنے کو فعال کریں۔ یہ فی درخواست نئے کنکشن قائم کرنے کے بجائے TCP کنکشنز کو دوبارہ استعمال کرتا ہے، TCP ہینڈ شیک اور TLS گفت و شنید کو ختم کرتا ہے (50-200ms فی نیا کنکشن)۔

---

اکثر پوچھے گئے سوالات

مجھے عوامی API کے لیے شرح کی کون سی حد مقرر کرنی چاہیے؟

قدامت پسند حدود کے ساتھ شروع کریں اور استعمال کے جائز نمونوں کی بنیاد پر ایڈجسٹ کریں۔ ایک عام نقطہ آغاز توثیق شدہ صارفین کے لیے فی منٹ 100 درخواستیں اور گمنام صارفین کے لیے 20 درخواستیں فی منٹ ہے۔ 429 رسپانس ریٹس کی نگرانی کریں -- اگر جائز صارفین کثرت سے حد کو مارتے ہیں تو ان میں اضافہ کریں۔ پریمیم API درجات کے لیے اعلیٰ حدیں فراہم کریں۔

جب صفحات کے درمیان ڈیٹا تبدیل ہوتا ہے تو میں صفحہ بندی کو کیسے ہینڈل کروں؟

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

کیا مجھے کارکردگی کے لیے REST یا GraphQL استعمال کرنا چاہیے؟

فیلڈ سلیکشن اور مناسب کیشنگ کے ساتھ REST سادہ، اچھی طرح سے طے شدہ اینڈ پوائنٹس کے لیے تیز تر ہے۔ گراف کیو ایل پیچیدہ ڈیٹا کے تقاضوں کے لیے اوور فیچنگ اور انڈر فیچنگ کو ختم کرتا ہے لیکن سوال کو پارس کرنے کے لیے اوور ہیڈ شامل کرتا ہے اور HTTP کیچنگ کو مشکل بنا دیتا ہے۔ کیشنگ کی ضروریات کے ساتھ عوامی APIs کے لیے REST اور پیچیدہ فرنٹ اینڈ ڈیٹا کی ضروریات کو پورا کرنے والے اندرونی APIs کے لیے GraphQL استعمال کریں۔

میں پیداوار میں API کی کارکردگی کی نگرانی کیسے کروں؟

P50، P95، اور P99 جوابی اوقات فی اختتامی نقطہ پر نظر رکھیں۔ اپنے SLO کی خلاف ورزی کرتے ہوئے P95 پر الرٹس سیٹ کریں (عام طور پر 200-500ms)۔ ڈیٹا بیس، کیشے، بیرونی خدمات، اور ایپلیکیشن لاجک میں گزارے گئے وقت کو توڑنے کے لیے تقسیم شدہ ٹریسنگ کا استعمال کریں۔ تفصیلی سیٹ اپ کے لیے مانیٹرنگ اور مشاہداتی پر ہماری گائیڈ دیکھیں۔

---

آگے کیا ہے۔

صفحہ بندی کی کمی کے لیے اپنے API اینڈ پوائنٹس کا آڈٹ کرکے شروع کریں، شرح کو محدود کیے بغیر غیر محفوظ عوامی اینڈ پوائنٹس، اور ہم وقت ساز آپریشنز جو async ہونے چاہئیں۔ یہ تین تبدیلیاں عام طور پر P95 کے جوابی اوقات کو 50-70% تک کم کرتی ہیں اور پیداوار کے سب سے عام واقعات کو روکتی ہیں۔

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

ECOSIRE کاروباری پلیٹ فارمز کے لیے Odoo ERP اور حسب ضرورت آرکیٹیکچرز کے لیے اعلیٰ کارکردگی والے APIs بناتا ہے۔ API کارکردگی کے جائزے کے لیے ہم سے رابطہ کریں۔

---

شائع کردہ بذریعہ ECOSIRE — کاروباروں کو Odoo ERP، Shopify eCommerce، اور OpenClaw AI میں AI سے چلنے والے حل کے ساتھ پیمانے میں مدد کرنا۔