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