AI API فیل اوور اور فال بیک روٹنگ: وہ سب کچھ جو آپ کو جاننے کی ضرورت ہے

زیادہ تر AI ایپس ایک سادہ انضمام سے شروع ہوتی ہیں۔

آپ ایک LLM پرووائیڈر منتخب کرتے ہیں، API key شامل کرتے ہیں، پرامپٹ بھیجتے ہیں، جواب حاصل کرتے ہیں، اور فیچر جاری کر دیتے ہیں۔

ایک پروٹو ٹائپ کے لیے یہ عموماً کافی ہوتا ہے۔

لیکن پروڈکشن مختلف ہے۔

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

اسی لیے AI API فیل اوور پروڈکشن-ریڈی LLM ایپلی کیشنز بنانے والی ٹیموں کے لیے ایک عملی ضرورت بن چکا ہے۔

ایک پرووائیڈر کے ہمیشہ دستیاب رہنے کا مفروضہ کرنے کے بجائے، قابلِ برداشت AI ایپس اس طرح ڈیزائن کی جاتی ہیں کہ مسئلہ ہوتے ہی راستہ بدل لیں۔

AI API فیل اوور کیا ہے؟

AI API فیل اوور ایک ریلائبلٹی پیٹرن ہے جس میں آپ کی ایپلیکیشن بنیادی راستہ ناکام ہونے پر خودکار طور پر بیک اپ AI ماڈل یا پرووائیڈر روٹ پر سوئچ کر جاتی ہے۔

ایک کمزور ڈائریکٹ انٹیگریشن کچھ یوں لگتی ہے:

Your App → Single AI Provider → Single Point of Failure

ایک زیادہ مضبوط آرکیٹیکچر اس طرح دکھتا ہے:

Your App → Unified LLM API Layer → Primary Model                                 → Fallback Model

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

صارف کو یہ جاننے کی ضرورت نہیں کہ درخواست کس ماڈل نے ہینڈل کی۔

انہیں بس جواب ملتا ہے۔

یہ AI API فیل اوور کا بنیادی مقصد ہے: پرووائیڈر-سائیڈ ناکامی کو صارف کو نظر آنے والی پروڈکٹ ناکامی کے بجائے پس منظر کی روٹنگ ایونٹ میں بدل دینا۔

سنگل پرووائیڈر AI ایپس کیوں نازک ہوتی ہیں

بہت سے AI پروڈکٹس اب بھی ایک پرووائیڈر کو براہِ راست API کالز کے گرد بنائے جاتے ہیں۔

اس کا مطلب عموماً یہ ہوتا ہے کہ ایپ گہری طرح منسلک ہو جاتی ہے:

• ایک API key
• ایک SDK
• ایک رسپانس فارمیٹ
• ایک ماڈل فہرست
• ایک بلنگ سسٹم
• ایک ریٹ لمٹ پالیسی
• ایک اپ ٹائم پروفائل

یہ ڈویلپمنٹ میں اچھا کام کر سکتا ہے، لیکن پروڈکشن میں خطرہ پیدا کرتا ہے۔

عام ناکامی کے مناظر میں شامل ہیں:

• پرووائیڈر آؤٹیجز AI پرووائیڈر دستیاب نہیں رہتا یا جزوی طور پر متاثر ہوتا ہے۔
• HTTP 429 ریٹ لمٹس آپ کی ایپ پرووائیڈر کی اجازت سے زیادہ درخواستیں بھیجتی ہے۔
• 5xx سرور ایررز پرووائیڈر عارضی بیک اینڈ غلطیاں واپس کرتا ہے۔
• لیٹنسی میں اچانک اضافہ ماڈل آپ کے پروڈکٹ تجربے کے لیے بہت سست جواب دیتا ہے۔
• ماڈل دستیابی میں تبدیلیاں ماڈل روٹ وقتی طور پر غیر دستیاب، متروک، یا محدود ہو سکتا ہے۔

ایک AI نیٹو SaaS پروڈکٹ کے لیے، یہ معمولی بیک اینڈ مسائل نہیں ہیں۔ اگر صارفین آپ کی ایپ پر لکھنے، کوڈ کرنے، سپورٹ خودکار بنانے، ڈیٹا خلاصہ کرنے، یا فیصلے کرنے کے لیے انحصار کرتے ہیں، تو LLM صرف ایک فیچر نہیں رہتا۔

یہ پروڈکٹ انفراسٹرکچر کا حصہ ہوتا ہے۔

جب AI API ناکام ہوتی ہے، تو پروڈکٹ تجربہ بھی اس کے ساتھ ناکام ہوتا ہے۔

ڈائریکٹ انٹیگریشن بمقابلہ متحدہ LLM API لیئر

حل یہ نہیں کہ آپ اپنے کوڈ بیس میں بے ترتیب طور پر متعدد پرووائیڈر SDKs شامل کر دیں۔

یہ عموماً کم کے بجائے زیادہ پیچیدگی پیدا کرتا ہے۔

اس سے بہتر پیٹرن یہ ہے کہ آپ اپنی ایپلیکیشن اور بیرونی ماڈل پرووائیڈرز کے درمیان ایک متحدہ LLM API لیئر رکھیں۔

اس کے بجائے:

Frontend → OpenAI SDKBackend Job → Anthropic SDKAgent Workflow → DeepSeek SDKVideo Feature → Separate Video API

یہ استعمال کریں:

Application → Unified API Layer → Multiple Models / Providers

یہ ابسرایکشن آپ کی ایپ کو ایک مستحکم انٹرفیس دیتا ہے جبکہ نیچے کی ماڈل لیئر کو بدلنے کی اجازت دیتا ہے۔

متحدہ API لیئر کے ساتھ، آپ کی ایپ یہ کر سکتی ہے:

• بنیادی بزنس لاجک کو دوبارہ لکھے بغیر ماڈلز تبدیل کریں
• جب پرائمری ماڈل ناکام ہو تو فال بیک روٹس شامل کریں
• ماڈل کے معیار اور لاگت کا آسانی سے موازنہ کریں
• وینڈر لاک اِن کم کریں
• مانیٹرنگ اور ایرر ہینڈلنگ کو معیاری بنائیں
• نئے ماڈلز تیزی سے شامل کریں

مثال کے طور پر، آپ کی اندرونی ماڈل کال سادہ رہ سکتی ہے:

await generateText({  messages,  model: "gpt-5.6",  temperature: 0.7});

آپ کی پروڈکٹ لاجک کو اس سے فرق نہیں پڑنا چاہیے کہ درخواست GPT-5.6، Claude، DeepSeek، Gemini، یا کسی اور موزوں ماڈل نے سر کی ہے۔

روٹنگ لاجک ماڈل انفراسٹرکچر لیئر میں ہونی چاہیے، نہ کہ ایپلیکیشن میں بکھری ہوئی۔

آپ کی ایپ کو کب پرووائیڈرز تبدیل کرنے چاہییں؟

ایک اچھا فیل اوور سسٹم عین مطابق ہونا چاہیے۔

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

ایک سادہ قاعدہ یہ ہے:

پرووائیڈر-سائیڈ ناکامیوں پر فیل اوور کریں۔ پہلے ایپلیکیشن-سائیڈ بگز درست کریں۔

مثال کے طور پر، 400 Bad Request، 401 Unauthorized، اور 403 Forbidden جیسی غلطیاں عموماً اس بات کی علامت ہوتی ہیں کہ آپ کی ریکویسٹ، آتھنٹیکیشن، یا ایکسس پرمشنز میں مسئلہ ہے۔ وہی خراب ریکویسٹ کسی دوسرے پرووائیڈر کو بھیجنا مسئلہ حل نہیں کرے گا۔

دوسری طرف، 429 Rate Limit، 502 Bad Gateway، 503 Service Unavailable، 504 Gateway Timeout، ریکویسٹ ٹائم آؤٹس، یا وقتی ماڈل عدم دستیابی خودکار فال بیک روٹنگ کے لیے بہتر امیدوار ہیں۔

ان صورتوں میں، پرائمری روٹ اوورلوڈ، غیر دستیاب، ریٹ-لمٹڈ، یا آپ کے لیٹنسی بجٹ کے لیے بہت سست ہو سکتا ہے۔ ایک بیک اپ روٹ پروڈکٹ تجربے کو مستحکم رکھنے میں مدد کر سکتا ہے۔

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

HTTP اسٹیٹس کے حوالے کے لیے، ڈویلپرز MDN کی HTTP 429 دستاویزات یا پرووائیڈر مخصوص API ایرر ڈاکیومنٹیشن جیسے Anthropic API errors دیکھ سکتے ہیں۔

ایک اچھا فیل اوور سسٹم عین مطابق ہونا چاہیے۔

یہ ہر چیز کو اندھا دھند ریٹرائی نہیں کرنا چاہیے، کیونکہ ہر غلطی پرووائیڈر کی ناکامی نہیں ہوتی۔ کچھ غلطیاں آپ کی اپنی ریکویسٹ، API key، پرمشنز، یا پرامپٹ ساخت کی وجہ سے ہوتی ہیں۔

ان غلطیوں پر فیل اوور نہ کریں

یہ غلطیاں عموماً اس بات کی علامت ہوتی ہیں کہ آپ کی ریکویسٹ یا کنفیگریشن میں مسئلہ ہے:

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

ان غلطیوں پر فیل اوور کو ٹرگر کریں

یہ خودکار فال بیک روٹنگ کے لیے بہتر امیدوار ہیں:

ایک سادہ قاعدہ:

پرائیڈر-سائیڈ کی ناکامیوں پر فیل اوور کریں۔ ایپلیکیشن-سائیڈ بگز پر فیل اوور نہ کریں۔

HTTP اسٹیٹس کے حوالے کے لیے، ڈویلپرز MDN کی HTTP 429 دستاویزات یا پرووائیڈر مخصوص API ایرر ڈاکیومنٹیشن جیسے Anthropic API errors دیکھ سکتے ہیں۔

Claude Code اور Cursor کے ساتھ مضبوط AI ایپس بنانا

Claude Code، Cursor، اور GitHub Copilot جیسے AI مدد یافتہ ڈویلپمنٹ ٹولز ٹیموں کو تیزی سے بنانے میں مدد دیتے ہیں۔

لیکن اس میں بڑا فرق ہے کہ کون سا کوڈ لوکل پر کام کرتا ہے اور کون سا پروڈکشن ٹریفک جھیل لیتا ہے۔

اگر آپ ایک AI کوڈنگ اسسٹنٹ سے کہیں:

Add an AI chat feature to my application using an LLM API.

تو وہ عموماً ایک ڈائریکٹ پرووائیڈر انٹیگریشن بنا دے گا۔

یہ ڈیمو کے لیے کام کر سکتا ہے، مگر پروڈکشن آرکیٹیکچر کو نازک بنا دیتا ہے۔

ایک بہتر پرامپٹ زیادہ مخصوص ہوتا ہے:

Create a unified LLM provider abstraction layer.​The application should call one stable internal interface.​Configure a primary model route and a fallback route through CometAPI.​If the primary route times out, returns HTTP 429, or returns a 5xx error, catch the exception and retry with the fallback model.​Do not retry 400, 401, or 403 errors.​Keep all provider-specific configuration separate from the core business logic.

یہ آؤٹ پٹ کو فیچر-لیول کوڈ سے آرکیٹیکچر-لیول کوڈ میں بدل دیتا ہے۔

یہی اصل فرق ہے “یہ چلتا ہے” اور “یہ پروڈکشن برداشت کر لیتا ہے” کے درمیان۔

آؤٹیج سے پہلے اوبزروایبلیٹی شامل کریں

فیل اوور تب زیادہ مفید ہوتا ہے جب آپ دیکھ سکیں کہ کیا ہو رہا ہے۔

اگر آپ کی ایپ خاموشی سے ماڈلز سوئچ کرے اور آپ اسے ٹریک نہ کریں، تو آپ اہم ریلائبلٹی مسائل کھو سکتے ہیں۔

ایک ہلکا پھلکا AI اوبزروایبلیٹی سیٹ اپ کو یہ ٹریک کرنا چاہیے:

• فعال روٹنگ اسٹیٹس اس وقت کون سا ماڈل یا پرووائیڈر ٹریفک ہینڈل کر رہا ہے؟
• فال بیک ایونٹ لاگز فال بیک کب ہوا، اور کیوں؟
• روٹ کے حساب سے ایرر ریٹس کیا 429s، ٹائم آؤٹس، یا 5xx ایررز بڑھ رہے ہیں؟
• لیٹنسی اور ٹائم-ٹو-فرسٹ-ٹوکن کیا پرائمری ماڈل بہت سست ہوتا جا رہا ہے؟
• ٹریفک ڈسٹری بیوشن کتنا ٹریفک پرائمری روٹ بمقابلہ فال بیک روٹس پر جا رہا ہے؟
• ماڈل روٹ کے حساب سے لاگت کیا فیل اوور آپ کی لاگت غیر متوقع طور پر بڑھا رہا ہے؟

یہ آپ کی ٹیم کو کنٹرول دیتا ہے۔

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

ریلیابلیٹی اندازوں کا کھیل نہیں ہونا چاہیے۔

یہ قابلِ مشاہدہ ہونی چاہیے۔

AI API فیل اوور کے لیے بہترین طریقے

AI API فیل اوور تب سب سے بہتر کام کرتا ہے جب اسے شروع میں ڈیزائن کیا جائے، نہ کہ پہلی آؤٹیج کے بعد ہنگامی پیچ کے طور پر۔

یہاں چند عملی اصول ہیں۔

واضح ٹائم آؤٹ تھریش ہولڈز مقرر کریں

پرائمری ماڈل کے لیے ہمیشہ انتظار نہ کریں۔

اپنے پروڈکٹ کے لیے لیٹنسی بجٹ طے کریں۔ مثال کے طور پر، ریئل ٹائم چیٹ انٹرفیس کو بیک گراؤنڈ رپورٹ جنریشن ورک فلو کے مقابلے کم ٹائم آؤٹ درکار ہو سکتا ہے۔

اگر پرائمری روٹ اس بجٹ سے تجاوز کرے، تو فال بیک ٹرگر کریں۔

خراب ریکویسٹس پر فیل اوور نہ کریں

اگر ریکویسٹ خراب ساخت کی ہو، غیر مجاز ہو، یا لازمی پیرا میٹرز غائب ہوں، تو پہلے ریکویسٹ درست کریں۔

فیل اوور کا مقصد پرووائیڈر-سائیڈ ناکامیوں سے صارفین کو بچانا ہے، ایپلیکیشن بگز کو چھپانا نہیں۔

ہم پلہ بیک اپ ماڈلز استعمال کریں

فال بیک ماڈل کا پرائمری ماڈل کے ساتھ یکساں ہونا ضروری نہیں، مگر اسے اسی صارف-سامنا کرنے والے کام کے لیے موزوں ہونا چاہیے۔

مثال کے طور پر:

• کوڈنگ ٹاسکس کو مضبوط کوڈنگ-قابل بیک اپ چاہیے۔
• کسٹمر سپورٹ ورک فلو کو ایسا ماڈل چاہیے جو ہدایات قابلِ اعتماد طریقے سے مانے۔
• تخلیقی ورک فلو میں ایسا ماڈل درکار ہے جو آؤٹ پٹ کوالٹی برقرار رکھے۔
• ویڈیو ورک فلو کو ایسا بیک اپ روٹ چاہیے جو اسی میڈیا ٹائپ کو سپورٹ کرے۔

ہر فال بیک ایونٹ لاگ کریں

ہر فال بیک ایونٹ لاگ ہونا چاہیے۔

ٹریک کریں:

• اصلی ماڈل
• بیک اپ ماڈل
• غلطی کی قسم
• ریکویسٹ لیٹنسی
• ریٹرائی کاؤنٹ
• حتمی اسٹیٹس
• متوقع لاگت

یہ آپ کی ٹیم کو سمجھنے میں مدد دیتا ہے کہ فال بیک توقع کے مطابق کام کر رہا ہے یا کسی گہرے انفراسٹرکچر مسئلے کو چھپا رہا ہے۔

فال بیک کوالٹی باقاعدگی سے جانچیں

ماڈلز تیزی سے بدلتے ہیں۔

جو فال بیک روٹ پچھلے مہینے اچھا تھا، وہ آج بہترین نہ ہو۔ قیمت، معیار، رفتار، اور دستیابی سب بدل سکتے ہیں۔

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

ریٹرائی بمقابلہ فیل اوور

ریٹرائی اور فیل اوور متعلقہ ہیں، مگر ایک جیسے نہیں۔

ریٹرائی وہی ریکویسٹ اسی ماڈل روٹ پر دوبارہ بھیجتا ہے۔

فیل اوور اس ریکویسٹ کو مختلف بیک اپ روٹ پر بھیجتا ہے جب پرائمری روٹ غیر دستیاب یا غیر قابلِ اعتماد معلوم ہو۔

ایک عملی پروڈکشن سیٹ اپ اکثر دونوں استعمال کرتا ہے۔

مثال کے طور پر:

Request → Primary Model → Short Retry → Fallback Model → Response

یہ بہت جارحانہ انداز میں روٹس سوئچ کرنے سے بچاتا ہے جبکہ جب پرائمری روٹ واقعی غیر صحت مند ہو تو صارف کے تجربے کو محفوظ رکھتا ہے۔

آخری خیالات: فیل اوور حد سے زائد انجینئرنگ نہیں ہے

ویک اینڈ سائیڈ پروجیکٹ کے لیے ایک پرووائیڈر پر انحصار قابلِ قبول ہو سکتا ہے۔

لیکن فعال صارفین والی پروڈکشن ایپلیکیشن کے لیے ایک پرووائیڈر پر انحصار ریلائبلٹی رسک ہے۔

بیرونی APIs سست ہو سکتی ہیں۔ ریٹ لمٹس تک پہنچا جا سکتا ہے۔ ماڈل روٹس غیر دستیاب ہو سکتے ہیں۔ کوٹاز بدل سکتے ہیں۔ پرووائیڈرز کے ساتھ واقعات پیش آ سکتے ہیں۔

سوال یہ نہیں کہ بیرونی APIs کبھی کبھار ناکام ہوں گے یا نہیں۔

سوال یہ ہے کہ کیا آپ کے صارفین اسے محسوس کریں گے۔

فیل اوور کے ساتھ ایک متحدہ LLM API لیئر پرووائیڈر مسئلے کو ایک کنٹرولڈ روٹنگ ایونٹ میں بدل دیتی ہے۔ یہ آپ کی ٹیم کو پروڈکٹ آن لائن رکھنے، وینڈر لاک اِن کم کرنے، ماڈل سوئچنگ آسان بنانے، اور AI انفراسٹرکچر کو زیادہ صاف انداز میں مینیج کرنے میں مدد دیتی ہے۔

پہلی آؤٹیج کا انتظار نہ کریں کہ پھر ریلائبلٹی ڈیزائن کریں۔

اپنا AI API فیل اوور لیئر شروع میں ہی بنائیں۔

آپ کے صارفین شاید کبھی نہ جانیں کہ اس نے ان کے تجربے کو بچا لیا — اور یہی اصل مقصد ہے۔

زیادہ قابلِ اعتماد AI ایپس بنانے کے لیے تیار ہیں؟ CometAPI سے شروعات کریں۔

عمومی سوالات

AI API فیل اوور کیا ہے؟

AI API فیل اوور ایک ریلائبلٹی پیٹرن ہے جس میں ایپلیکیشن بنیادی AI ماڈل یا پرووائیڈر روٹ سے خودکار طور پر بیک اپ روٹ کی طرف سوئچ کرتی ہے جب بنیادی روٹ ناکام ہو، ٹائم آؤٹ ہو، ریٹ لمٹس سے ٹکرائے، یا غیر دستیاب ہو جائے۔

LLM ایپس کو فیل اوور کی کیوں ضرورت ہے؟

LLM ایپس کو فیل اوور کی ضرورت ہے کیونکہ بیرونی AI پرووائیڈرز میں آؤٹیجز، ریٹ لمٹس، لیٹنسی اسپائکس، یا وقتی ماڈل دستیابی کے مسائل آ سکتے ہیں۔ فیل اوور کے بغیر، ایک پرووائیڈر کا مسئلہ پورے صارف تجربے کو توڑ سکتا ہے۔

کیا ہر API ایرر پر فیل اوور ہونا چاہیے؟

نہیں۔ 400 Bad Request، 401 Unauthorized، اور 403 Forbidden جیسی غلطیاں عموماً آپ کی ریکویسٹ، API key، یا پرمشنز کے مسائل کی نشاندہی کرتی ہیں۔ فیل اوور زیادہ مفید ہے ٹائم آؤٹس، 429 ریٹ لمٹس، 5xx سرور ایررز، اور غیر دستیاب ماڈل روٹس کے لیے۔

ریٹرائی اور فیل اوور میں کیا فرق ہے؟

ریٹرائی وہی ریکویسٹ اسی روٹ کو دوبارہ بھیجتا ہے۔ فیل اوور اس ریکویسٹ کو بیک اپ ماڈل یا پرووائیڈر روٹ پر بھیجتا ہے جب پرائمری روٹ غیر دستیاب یا غیر قابلِ اعتماد ہو۔

CometAPI AI API فیل اوور میں کیسے مدد دیتا ہے؟

CometAPI متعدد AI ماڈلز تک ایک ہی اینڈ پوائنٹ کے ذریعے رسائی کے لیے OpenAI-کمپیٹبل API لیئر فراہم کرتا ہے۔ اس سے ڈویلپرز کے لیے ماڈلز ٹیسٹ کرنا، روٹس سوئچ کرنا، اور فیل اوور اسٹریٹجیز ڈیزائن کرنا آسان ہو جاتا ہے، بغیر ہر پرووائیڈر انٹیگریشن کو دوبارہ بنانے کے۔

کیا میں GPT-5.6 کو پرائمری روٹ اور کسی دوسرے ماڈل کو فال بیک کے طور پر استعمال کر سکتا/سکتی ہوں؟

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