𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
मैंने एक कम्युनिटी फोरम के लिए एक रियल-टाइम चैटबॉट बनाया। मुझे लगा कि सिर्फ एक API का उपयोग करना काफी होगा। मैं गलत था।
तीन हफ्ते बाद, पीक आवर्स (peak hours) के दौरान मुझे 5xx एरर का सामना करना पड़ा। मेरा चैटबॉट बंद हो गया। यूजर्स परेशान थे। मुझे एहसास हुआ कि प्रोडक्शन ऐप्स के लिए मैं केवल एक प्रोवाइडर पर भरोसा नहीं कर सकता।
मैंने GPT-4 का उपयोग किया। यह तब तक अच्छा काम करता रहा जब तक कि अचानक काम करना बंद नहीं कर दिया। मुझे रेट लिमिट्स (rate limits), टाइमआउट्स और पूरी तरह से आउटेज (outages) का सामना करना पड़ा। हायर टियर्स (higher tiers) के लिए भुगतान करना समस्या को हल करने के बजाय केवल उसके लक्षणों को ठीक करने जैसा लग रहा था।
मैंने अन्य प्रोवाइडर्स को आज़माया, लेकिन उन सभी के फॉर्मेट और ऑथेंटिकेशन (auth) तरीके अलग-अलग थे। मेरा कोड switch-case स्टेटमेंट्स का एक ढेर बन गया। मुझे एक ऐसे सिस्टम की ज़रूरत थी जो:
- प्रोवाइडर के अंतरों को छिपा सके।
- फेल होने पर बैकअप प्रोवाइडर पर स्विच कर सके।
- रिस्पॉन्स को कैश (cache) कर सके।
- वेंडर लॉक-इन (vendor lock-in) से बच सके।
मैंने थर्ड-पार्टी लाइब्रेरीज़ से परहेज किया क्योंकि वे बहुत जटिल थीं और आसानी से टूट जाती थीं। इसके बजाय, मैंने एक सिंपल राउटर बनाया।
सबसे पहले, मैंने सभी प्रोवाइडर्स के लिए एक कॉमन इंटरफ़ेस (common interface) परिभाषित किया। प्रत्येक प्रोवाइडर एक generate मेथड और एक हेल्थ चेक (health check) को लागू करता है।
इसके बाद, मैंने एक राउटर क्लास बनाई। यह एक विशिष्ट क्रम में प्रोवाइडर्स को आज़माता है। यह एक्सपोनेंशियल बैकऑफ़ (exponential backoff) और एक सिंपल कैश का उपयोग करता है। यदि पहला प्रोवाइडर विफल हो जाता है, तो सिस्टम प्रतीक्षा करता है और अगले प्रोवाइडर को आज़माता है।
इस सिस्टम ने तीन अलग-अलग आउटेज के दौरान मेरे वीकेंड्स बचा लिए। यह मेरे ऐप को तब भी चालू रखता है जब कोई बड़ा प्रोवाइडर डाउन हो जाता है।
यदि आप इसे बनाते हैं, तो इन बातों का ध्यान रखें:
- प्रोडक्शन में लोकल डिक्शनरी के बजाय कैशिंग के लिए Redis का उपयोग करें।
- हेल्थ चेक सफलता की गारंटी नहीं देते हैं। एक प्रोवाइडर चेक पास कर सकता है लेकिन वास्तविक अनुरोध (request) में विफल हो सकता है।
- रेट लिमिट्स को ठीक से संभालने के लिए Retry-After हेडर्स को पार्स (parse) करें।
- लागत को ट्रैक करने के लिए टोकन उपयोग के लिए लॉगिंग (logging) जोड़ें।
- बेहतर परफॉरमेंस के लिए
asyncioका उपयोग करें।
यदि आपका प्रोजेक्ट छोटा है, तो ओवर-इंजीनियरिंग न करें। यदि आपको स्ट्रीमिंग की आवश्यकता है, तो यह पैटर्न लेटेंसी (latency) बढ़ा सकता है। अपने स्केल के लिए सही टूल चुनें।
आप प्रोवाइडर की विश्वसनीयता (reliability) को कैसे संभालते हैं? क्या आप एक ही प्रोवाइडर पर टिके रहते हैं या एक फॉलबैक लेयर (fallback layer) बनाते हैं?
Optional learning community: https://t.me/GyaanSetuAi