रेट लिमिट से परे: Codex और Sora के लिए एक्सेस का विस्तार

पिछले एक साल में, Codex और Sora दोनों का तेजी से अपनाया गया है, और उनका उपयोग हमारी मूल अपेक्षाओं से कहीं आगे बढ़ गया है. हमने एक लगातार पैटर्न देखा है: उपयोगकर्ता शुरुआत में गहराई से जुड़ते हैं, वास्तविक मूल्य पाते हैं, और फिर दर सीमाओं से टकरा जाते हैं.

रेट लिमिट्स डिमांड को स्मूथ करने और फेयर एक्सेस सुनिश्चित करने में मदद कर सकती हैं; हालांकि, जब यूज़र्स को वैल्यू मिल रही होती है, तो हार्ड स्टॉप निराशाजनक हो सकता है. हम यूज़र्स के लिए आगे बढ़ते रहने का एक तरीका चाहते थे, साथ ही सिस्टम परफ़ॉर्मेंस की सुरक्षा करते हुए और अपनी अप्रोच में यूज़र ट्रस्ट बनाए रखते हुए.

इसे हल करने के लिए, हमने एक रियल-टाइम एक्सेस इंजन बनाया जो उपयोग को गिनता है. उस इंजन की परतों में से एक क्रेडिट खरीदने की क्षमता है. जब उपयोगकर्ता अपनी दर सीमाएं पार कर लेते हैं, तो क्रेडिट उन्हें अपने क्रेडिट बैलेंस को खर्च करके हमारे उत्पादों का उपयोग जारी रखने की अनुमति देते हैं.

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

ज़ूम आउट करने पर, पारंपरिक एक्सेस मॉडल अक्सर एक विकल्प चुनने के लिए मजबूर करते हैं:

• रेट लिमिट्स शुरुआत में मददगार हो सकती हैं, लेकिन जब वे खत्म हो जाती हैं, तो उपयोगकर्ताओं को खराब अनुभव होता है: “बाद में वापस आएं”
• उपयोग‑आधारित बिलिंग लचीली है, लेकिन उपयोगकर्ताओं को पहले टोकन से ही भुगतान करना पड़ता है—प्रारंभिक अन्वेषण के लिए आदर्श नहीं है

Codex और Sora के लिए, इनमें से कोई भी अकेले पर्याप्त नहीं था. अगर हम केवल रेट लिमिट्स बढ़ा दें, तो हम मांग को सुचारू करने और निष्पक्षता के महत्वपूर्ण नियंत्रण खो देंगे और सभी को सेवा देने की हमारी क्षमता समाप्त हो जाएगी. अगर हम पूरी तरह से असिंक्रोनस उपयोग बिलिंग पर निर्भर होते, तो हम विलंब, ओवरएज, या समेटने से जुड़ी समस्याएँ पैदा कर देते—बिल्कुल वही समस्याएँ जिन्हें उपयोगकर्ता तब नोटिस करते हैं जब वे सबसे अधिक संलग्न होते हैं.

इसके बजाय हमें एक ऐसा हाइब्रिड सिस्टम चाहिए था जो रियल-टाइम लिमिट्स को पे-एज़-यू-गो एक्सेस के साथ जोड़ सके:

इस सिस्टम को यह करना था:

• रेट लिमिट्स लागू करें जब तक की वे पूरी तरह पूरी न हो जाएं
• बिना किसी रुकावट के क्रेडिट्स में बदलाव करें उसी अनुरोध के भीतर
• उस निर्णय को वास्तविक समय में लें
• क्रेडिट खपत को ट्रैक करते समय सटीकता और ऑडिट की क्षमता बनाए रखें

हमारे द्वारा किए गए प्रमुख वैचारिक बदलावों में से एक था एक्सेस को निर्णय जलप्रपात के रूप में मॉडल करना. “क्या यह अनुमति है?” पूछने के बजाय, हम पूछते हैं “कितनी अनुमति है, और कहाँ से?” उपयोग की गणना करते समय, सिस्टम निम्नलिखित क्रम से गुजरता है:

यह मॉडल दिखाता है कि उपयोगकर्ता वास्तव में उत्पाद का अनुभव कैसे करते हैं. रेट लिमिट्स, फ्री टियर, क्रेडिट्स, प्रमोशन्स, और एंटरप्राइज़ एंटाइटलमेंट्स—ये सभी एक ही निर्णय स्टैक में बस अलग-अलग परतें हैं. यूज़र के नज़रिए से, वे 'सिस्टम स्विच' नहीं करते—वे बस Codex और Sora का उपयोग करते रहते हैं. इसीलिए क्रेडिट्स अदृश्य लगते हैं: वे वॉटरफ़ॉल में सिर्फ एक और तत्व हैं.

हमने क्रेडिट खपत को प्रबंधित करने के लिए थर्ड-पार्टी उपयोग बिलिंग और मीटरिंग प्लेटफ़ॉर्म का मूल्यांकन किया. वे इनवॉइसिंग और रिपोर्टिंग के लिए अच्छी तरह से उपयुक्त हैं, लेकिन दो महत्वपूर्ण आवश्यकताओं को पूरा नहीं कर सके:

जब कोई उपयोगकर्ता किसी सीमा पर पहुँचता है और उसके पास क्रेडिट्स उपलब्ध होते हैं, तो सिस्टम को तुरंत पता चलना चाहिए. सर्वोत्तम प्रयास या देरी से की गई गणना अप्रत्याशित ब्लॉक्स, असंगत बैलेंस, और गलत शुल्क के रूप में प्रकट होती है. Codex और Sora जैसे इंटरैक्टिव उत्पादों के लिए, ये विफलताएँ स्पष्ट और निराशाजनक हो जाती हैं.

हमें हर परिणाम में पारदर्शिता भी देनी थी:

• किसी अनुरोध को अनुमति क्यों दी गई या उसे ब्लॉक क्यों किया गया
• इसने कितना उपयोग किया है
• कौन-सी सीमाएं या संतुलन लागू किए गए थे

इस क्षमता को अलग-थलग रूप से, एक अलग उपयोग बिलिंग प्लेटफ़ॉर्म में हल करने के बजाय, हमारे डिसीजन वॉटरफॉल में कसकर इंटीग्रेटेड होना ज़रूरी था, जो केवल हो रही चीज़ों के एक हिस्से को ही देखता था. उपयोगकर्ताओं को भरोसे से समझौता किए बिना हमारे उत्पादों तक पहुंच प्रदान करने के लिए, हमें शुद्धता, समय-निर्धारण और अवलोकनीयता पर पूर्ण नियंत्रण की आवश्यकता थी. इसने हमें इन-हाउस समाधान की ओर प्रेरित किया.

इसे संचालित करने के लिए, हमने एक वितरित उपयोग और संतुलन प्रणाली बनाई है, जिसे विशेष रूप से समकालिक पहुंच निर्णयों के लिए डिज़ाइन किया गया है.

उच्च स्तर पर, सिस्टम:

• प्रति उपयोगकर्ता, प्रति-विशेषता उपयोग को ट्रैक करता है
• रेट लिमिट विंडो को बनाए रखता है
• रीयल-टाइम क्रेडिट बैलेंस बनाए रखता है
• स्ट्रीमिंग असिंक प्रोसेसर के माध्यम से बैलेंस को आइडेम्पोटेंट तरीके से डेबिट करता है

हर अनुरोध एकल मूल्यांकन पथ से गुज़रता है, जो रेट लिमिट्स से समकालिक रूप से खपत करके और, यदि आवश्यक हो, पर्याप्त क्रेडिट्स की पुष्टि करके वास्तविक समय में यह निर्णय लेता है कि कितना उपयोग अनुमत है; फिर यह क्रेडिट डेबिट्स को असमकालिक रूप से निपटाते हुए एक निश्चित परिणाम प्रदान करता है. यह उत्पादों के बीच सुसंगत व्यवहार सुनिश्चित करता है और टीमों के बीच दोहराए गए तर्क को समाप्त करता है.

इस सिस्टम के प्रमुख डिज़ाइन सिद्धांतों में से एक यह है कि हम यह साबित कर सकें कि हमारी बिलिंग सही है. यह हमारे क्रेडिट समर्थन की जड़ों को दर्शाता है, जो एंटरप्राइज़ ग्राहकों के साथ शुरू हुआ था. ऊपर दिए गए सिस्टम आरेख में, हमारे पास तीन अलग-अलग डेटासेट हैं जो सभी एक साथ जुड़े हुए हैं:

• प्रोडक्ट इस्तेमाल इवेंट: यूज़र ने असल में क्या किया
• मोनेटाइज़ेशन इवेंट्स: हम उपयोगकर्ता से उनके उपयोग के लिए क्या शुल्क लेते हैं
• बैलेंस अपडेट: हमने उपयोगकर्ता के क्रेडिट बैलेंस को कितना समायोजित किया और इसका कारण क्या है

ये डेटासेट्स कोई साधारण उप-उत्पाद नहीं हैं; वे वास्तव में सिस्टम को संचालित करते हैं, और प्रत्येक डेटासेट अगले को सक्रिय करता है. जो हुआ, उससे जुड़े किसी भी शुल्क और हमने जो डेबिट किया, उन्हें अलग करने से हम प्रत्येक स्तर का स्वतंत्र रूप से ऑडिट, पुनः चलाना और सामंजस्य स्थापित कर सकते हैं. यह एक जानबूझकर किया गया ट्रेड-ऑफ है, जिसमें हम क्रेडिट बैलेंस अपडेट में थोड़ी देरी होने की कीमत पर, प्रमाणित रूप से सही होने को प्राथमिकता दे रहे हैं. हमने इसे कैसे पूरा किया:

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

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

हमारे दृष्टिकोण के पीछे का मुख्य सिद्धांत उपयोगकर्ता की गति की रक्षा करना है. हर आर्किटेक्चरल निर्णय का एक यूज़र-फेसिंग परिणाम होता है: रियल-टाइम बैलेंस अनावश्यक व्यवधानों को रोकते हैं, एटॉमिक कंज़म्प्शन डबल-चार्जिंग को रोकता है, और यूनिफ़ाइड एक्सेस लॉजिक पूर्वानुमेय व्यवहार सुनिश्चित करता है. नतीजा यह है कि लोग लंबे समय तक काम कर सकते हैं, गहराई से खोज कर सकते हैं, और बिना किसी कठोर रुकावट या समय से पहले योजना में बदलाव का सामना किए प्रोजेक्ट्स को आगे बढ़ा सकते हैं.

जब उपयोगकर्ता संलग्न होते हैं, तो सिस्टम को उन्हें आगे बढ़ने में मदद करनी चाहिए, न कि उनके रास्ते में रुकावट बनना चाहिए. सीमाएँ और क्रेडिट्स पृष्ठभूमि में गायब हो जाते हैं.

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