दर मर्यादांपलीकडे: Codex आणि Sora साठी प्रवेशाचा विस्तार

मागील वर्षात, Codex आणि Sora या दोन्हींचा जलद स्वीकार झाला आहे, आणि त्यांचा वापर आमच्या मूळ अपेक्षेपेक्षा अधिक वेगाने वाढला आहे. आम्ही एक सातत्यपूर्ण नमुना पाहिला आहे: वापरकर्ते लगेच सुरुवात करतात, खरे मूल्य शोधतात आणि नंतर दर मर्यादांना सामोरे जातात.

रेट लिमिट्स मागणी सुरळीत करण्यात आणि न्याय्य प्रवेश सुनिश्चित करण्यात मदत करू शकतात; तथापि, जेव्हा वापरकर्त्यांना मूल्य मिळत असते, तेव्हा अचानक थांबवणे त्रासदायक ठरू शकते. वापरकर्ते पुढे चालू ठेवू शकतील असा मार्ग आम्हाला हवा होता, आणि त्याच वेळी प्रणालीची कार्यक्षमता आणि आमच्या दृष्टिकोनावर वापरकर्त्यांचा विश्वास जपायचा होता.

हे सोडवण्यासाठी, आम्ही वापर मोजण्यासाठी रिअल-टाइम प्रवेश इंजिन तयार केले. त्या इंजिनमधील एक स्तर म्हणजे क्रेडिट्स खरेदी करण्याची क्षमता आहे. जेव्हा वापरकर्ते त्यांच्या दर मर्यादा ओलांडतात, तेव्हा क्रेडिट्स त्यांना त्यांच्या क्रेडिट शिल्लक रकमेचा वापर करून आमची उत्पादने वापरणे सुरू ठेवण्यास अनुमती देतात.

याच्या खाली एक जटिल प्रणाली आहे जी मर्यादा, रिअल-टाइम वापर ट्रॅकिंग, आणि क्रेडिट शिल्लक यांना एका एकल प्रवेश मॉडेलमध्ये एकत्र करते. ही पोस्ट Codex आणि Sora च्या स्केलिंगसाठी प्रवेश नियंत्रणाचा पुनर्विचार का आवश्यक होता, सिद्धपणे योग्य, रिअल-टाइम प्रणाली कशी प्रति विनंती रेट लिमिट्स आणि क्रेडिट्स एकत्रित करते, आणि तो पाया आता दोन्ही उत्पादनांसाठी अतिरिक्त प्रवेश कसा सक्षम करतो याबद्दल माहिती देते.

थोडे दूरून पाहिल्यास, पारंपरिक प्रवेश मॉडेल्स सहसा एक निवड करण्यास भाग पाडतात:

• दर मर्यादा सुरुवातीला उपयुक्त ठरू शकतात, परंतु त्या संपल्यावर वापरकर्त्यांना वाईट अनुभव येतो: “नंतर परत या”
• वापर-आधारित बिलिंग लवचिक आहे, परंतु वापरकर्त्यांना पहिल्या टोकनपासूनच पैसे द्यावे लागतात—प्रारंभिक अन्वेषणासाठी हे आदर्श नाही

Codex आणि Sora साठी, कोणतेही एकटे पुरेसे नव्हते. जर आम्ही फक्त दर मर्यादा वाढवल्या, तर आम्ही मागणी-समतोल आणि न्याय्यतेसाठीची महत्त्वाची नियंत्रणे गमावू आणि सर्वांना सेवा देण्यासाठीची क्षमता संपेल. जर आम्ही पूर्णपणे असिंक्रोनस वापर बिलिंगवर अवलंबून राहिलो, तर आम्ही विलंब, अतिरिक्त शुल्क, किंवा ताळमेळ साधण्याच्या समस्या निर्माण करू—अशा समस्या ज्या वापरकर्त्यांना त्यांच्या सर्वाधिक सहभागाच्या वेळी जाणवतात.

त्याऐवजी आम्हाला आवश्यक होती एकच हायब्रिड प्रणाली जी वास्तविक-वेळेतील मर्यादा आणि पे-एज-यू-go प्रवेश एकत्र करते:

या प्रणालीला हे करावे लागले:

• मर्यादा गाठेपर्यंत दर मर्यादा अंमलात आणा
• त्याच विनंतीमध्ये अखंडपणे क्रेडिट्सकडे संक्रमण करा
• तो निर्णय तात्काळ घ्या
• क्रेडिट वापराचा मागोवा घेताना काटेकोर अचूकता आणि ऑडिट करण्यायोग्यता सुनिश्चित करा

आम्ही केलेल्या महत्त्वाच्या संकल्पनात्मक बदलांपैकी एक म्हणजे प्रवेशाचे मॉडेलिंग निर्णय प्रवाह म्हणून करणे. “हे परवानगी आहे का?” असे विचारण्याऐवजी, आम्ही विचारतो “किती परवानगी आहे, आणि कुठून?” वापर मोजताना, प्रणाली खालील क्रमाने जाते:

हे मॉडेल वापरकर्ते उत्पादनाचा प्रत्यक्षात कसा अनुभव घेतात हे दर्शवते. रेट मर्यादा, फ्री टियर, क्रेडिट्स, प्रमोशन्स आणि एंटरप्राइझ एंटायटलमेंट्स हे सर्व एकाच निर्णय स्टॅकमधील स्तर आहेत. वापरकर्त्याच्या दृष्टीकोनातून, ते "सिस्टीम बदलत" नाहीत—ते फक्त Codex आणि Sora वापरतच राहतात. म्हणूनच क्रेडिट्स अदृश्य वाटतात: ते फक्त धबधब्याचा आणखी एक घटक आहेत.

आम्ही क्रेडिट वापर व्यवस्थापित करण्यासाठी तृतीय पक्ष बिलिंग आणि मीटरिंग प्लॅटफॉर्मचे मूल्यांकन केले. ते इनव्हॉइसिंग आणि रिपोर्टिंगसाठी चांगले अनुकूल आहेत, परंतु दोन महत्त्वाच्या आवश्यकतांची पूर्तता झाली नाही:

जेव्हा एखादा वापरकर्ता मर्यादा गाठतो आणि क्रेडिट्स उपलब्ध असतात, तेव्हा प्रणालीला तत्काळ माहिती असणे आवश्यक आहे. सर्वोत्तम‑प्रयत्न किंवा विलंबित मोजणीमुळे अनपेक्षित ब्लॉक्स, विसंगत शिल्लक आणि चुकीचे शुल्क दिसतात. Codex आणि Sora सारख्या इंटरॅक्टिव्ह उत्पादनांसाठी, ती अपयशे स्पष्टपणे दिसतात आणि त्रासदायक ठरतात.

आम्हाला प्रत्येक परिणामामध्ये पारदर्शकता प्रदान करणे देखील आवश्यक होते:

• विनंतीला परवानगी का देण्यात आली किंवा ती अवरोधित का करण्यात आली
• वापर किती झाला
• कोणती मर्यादा किंवा शिल्लक लागू केली गेली होती

ही क्षमता फक्त जे घडत होते त्यातील एकच भाग पाहणाऱ्या स्वतंत्र वापर-बिलिंग प्लॅटफॉर्ममध्ये वेगळेपणाने सोडवण्याऐवजी, आमच्या निर्णय-जलप्रपातामध्ये घट्टपणे एकत्रित करणे आवश्यक होते. वापरकर्त्यांना विश्वासाशी तडजोड न करता आमच्या उत्पादनांमध्ये प्रवेश मिळावा यासाठी, आम्हाला अचूकता, वेळेचे नियोजन आणि निरीक्षणक्षमता यांवर पूर्ण नियंत्रण आवश्यक होते. त्यामुळे आम्ही अंतर्गत उपायाकडे वळलो.

हे कार्यान्वित करण्यासाठी, आम्ही समकालिक प्रवेश निर्णयांसाठी खास डिझाइन केलेली वितरित वापर आणि शिल्लक प्रणाली तयार केली.

उच्च स्तरावर, प्रणाली:

• प्रति‑वापरकर्ता, प्रति‑वैशिष्ट्य वापर ट्रॅक करते
• रेट मर्यादा विंडो राखते
• रिअल‑टाइम क्रेडिट शिल्लक राखतो
• स्ट्रीमिंग असिंक प्रोसेसरद्वारे शिल्लक रक्कम आयडेम्पोटेंटली डेबिट करते

प्रत्येक विनंती एकाच मूल्यांकन मार्गातून जाते, जो रिअल‑टाइममध्ये किती वापर परवानगी आहे याबद्दल निर्णय घेतो, रेट लिमिट्समधून समकालिकपणे वापर खर्च करून आणि, गरज असल्यास, पुरेसे क्रेडिट्स आहेत का ते पडताळतो; त्यानंतर कोणतेही क्रेडिट डेबिट्स असमकालिकपणे सेटल करताना एकच निश्चित परिणाम परत करतो. हे उत्पादनांमध्ये सातत्यपूर्ण वर्तन सुनिश्चित करते आणि संघांमध्ये पुनरावृत्त लॉजिक काढून टाकते.

या प्रणालीच्या प्रमुख डिझाइन तत्त्वांपैकी एक म्हणजे आमचे बिलिंग योग्य आहे हे आम्ही सिद्ध करू शकले पाहिजे. हे आमच्या क्रेडिट समर्थनाच्या मुळांचे प्रतिबिंब आहे, ज्याची सुरुवात एंटरप्राइज ग्राहकांपासून झाली. वरील प्रणाली आरेखात, आमच्याकडे तीन स्वतंत्र डेटासेट्स आहेत जे एकत्र जोडलेले आहेत:

• उत्पादन वापर कार्यक्रम: वापरकर्त्याने प्रत्यक्षात काय केले
• मॉनेटायझेशन इव्हेंट्स: वापरकर्त्याच्या वापरासाठी आम्ही त्यांच्याकडून शुल्क कसे आकारतो
• शिल्लक अद्यतने: आम्ही वापरकर्त्याच्या क्रेडिट शिल्लक रकमेतील बदल किती केला आणि का

हे डेटासेट्स सहज उपउत्पादन नाहीत; प्रत्यक्षात ते प्रणाली चालवतात, आणि प्रत्येक डेटासेट पुढील डेटासेटला ट्रिगर करते. घडलेल्या घटनांचे, संबंधित शुल्कांचे, आणि आम्ही डेबिट केलेल्या रकमेचे विभाजन केल्याने आम्हाला प्रत्येक स्तराचे स्वतंत्रपणे ऑडिट, पुनरावलोकन, आणि समेट करता येतो. हा एक जाणूनबुजून केलेला तडजोड आहे, जिथे आम्ही सिद्ध करता येण्याजोग्या अचूकतेला प्राधान्य देत आहोत, ज्यामुळे क्रेडिट शिल्लक अद्यतने थोडी उशिरा होऊ शकतात. आम्ही हे कसे साध्य केले:

• क्रेडिट वापर होतो की नाही याची पर्वा न करता, सर्व वापरकर्ता क्रियाकलापांसाठी उत्पादन वापर इव्हेंट्स प्रकाशित केले जातात. हे वापरकर्त्याच्या क्रियाकलापांसाठी ऑडिट ट्रेल प्रदान करते आणि आम्हाला क्रेडिट्सचे शुल्क का आकारले किंवा का आकारले नाही, हे स्पष्ट करण्यास अनुमती देते.
• प्रत्येक घटनेसोबत एक स्थिर आयडेम्पोटेंसी की असते, त्यामुळे पुनःप्रयत्न, पुनःप्रसारण किंवा वर्कर पुन्हा सुरू केल्याने कधीही शिल्लक रक्कम दुहेरीपणे डेबिट होत नाही, ज्यामुळे दुहेरी‑शुल्क आकारणी टाळता येते. यामुळे आम्हाला आमचे काम ऑफलाइन पडताळण्यासाठी बॅच पुनर्मिलन चालवता येते.
• ऑडिट ट्रेल तयार करण्यासाठी आम्ही समकालिक अपडेट्सऐवजी असमकालिक (पण तरीही जवळजवळ रिअल-टाइम) बॅलन्स अपडेट्स करतो. आम्ही वापरकर्त्याच्या शिल्लक अद्ययावत करण्यात थोडा विलंब सहन करतो, जेणेकरून आम्ही प्रणाली कार्यरत असल्याचे सिद्ध करू शकू आणि आमच्या वापरकर्त्यांना खात्री देऊ शकू की आम्ही त्यांना चुकीचे बिल लावत नाही. जेव्हा त्या थोडक्यात विलंबामुळे आम्ही वापरकर्त्याच्या क्रेडिट शिल्लक रकमेपेक्षा जास्त वसुली करतो, तेव्हा आम्ही ती आपोआप परत करतो; आम्ही कठोर अंमलबजावणीपेक्षा सिद्ध करता येण्याजोगी अचूकता आणि वापरकर्त्यांचा विश्वास यांना प्राधान्य देतो.
• आम्ही क्रेडिट शिल्लक कमी करतो आणि एका एकाच अणु डेटाबेस व्यवहारात शिल्लक अद्यतन नोंद समाविष्ट करतो. शिल्लक अद्यतने प्रत्येक खात्यासाठी अनुक्रमित केली जातात, त्यामुळे एकाच वेळी येणाऱ्या विनंत्या कधीही त्याच क्रेडिट्स खर्च करण्यासाठी स्पर्धा करू शकत नाहीत. शिल्लक अद्यतन रेकॉर्डमध्ये डेबिट रक्कम आणि अद्यतनाला ट्रिगर करणाऱ्या मोनेटायझेशन इव्हेंटकडे परत जाणारे अ‍ॅट्रिब्युशन समाविष्ट आहे; हे एका एकाच डेटाबेस व्यवहारात गुंडाळल्याने क्रेडिट शिल्लक रकमेतील प्रत्येक समायोजनासाठी आमच्याकडे ऑडिट ट्रेलची हमी मिळते.

ही सर्व काटेकोरता एका उद्दिष्टाला पाठिंबा देते: प्रवेश सोपा आणि सुरक्षित करणे. जेव्हा लोक काहीतरी तयार करत आहेत किंवा कोडिंग करत आहेत, त्यावेळी त्यांना एखादी विनंती जाईल का, त्यांच्याकडून जास्त शुल्क आकारले जाईल का, किंवा त्यांचा शिल्लक अचूक आहे का याची चिंता करावी लागू नये. वापर, बिलिंग आणि शिल्लक यांना पडताळता येईल इतके अचूक करून, आम्ही वापरकर्त्यांना अशी प्रणाली देतो जी त्यांच्या अनुभवात अडथळा आणत नाही. हेच आम्हाला हार्ड स्टॉप्सच्या जागी सातत्यपूर्ण प्रवेश देण्यास अनुमती देते—आणि हेच कारण आहे की क्रेडिट्स प्रत्यक्ष कामाच्या मधोमध वापरण्यायोग्य बनतात, केवळ इनव्हॉइसवरच नाही.

आमच्या दृष्टिकोनामागील मार्गदर्शक तत्त्व म्हणजे वापरकर्त्यांच्या गतीचे संरक्षण करणे. प्रत्येक आर्किटेक्चरल निर्णय वापरकर्त्यांसमोर दिसणाऱ्या परिणामाशी जोडलेला असतो: रिअल-टाइम शिल्लक अनावश्यक व्यत्यय टाळतात, अणुगत वापर दुहेरी शुल्क आकारणे टाळतो, आणि एकसंध प्रवेश तर्कसंगत आणि अंदाजयोग्य वर्तन सुनिश्चित करतो. परिणाम असा आहे की लोक अधिक काळ काम करू शकतात, अधिक सखोलपणे शोध घेऊ शकतात, आणि कठोर थांबे किंवा अकाली योजना बदलांना सामोरे न जाता प्रकल्पांना आणखी पुढे नेऊ शकतात.

जेव्हा वापरकर्ते गुंतलेले असतात, तेव्हा प्रणालीने त्यांना पुढे जाण्यास मदत करावी, अडथळा ठरू नये. मर्यादा आणि क्रेडिट्स पार्श्वभूमीत विलीन होतात.

तो अनुभव तयार करण्यासाठी प्रवेश, वापर आणि बिलिंग यांचा एकच प्रणाली म्हणून पुनर्विचार करणे आणि अचूकतेला प्रथम‑श्रेणीतील उत्पादन वैशिष्ट्य मानणारे इन्फ्रास्ट्रक्चर तयार करणे आवश्यक होते. हाच पाया कालांतराने अधिक उत्पादनांपर्यंत विस्तारू शकतो; Codex आणि Sora ही केवळ सुरुवात आहे.