રેટ લિમિટ્સથી આગળ: Codex અને Sora માટે ઍક્સેસ સ્કેલ કરવું

ગયા વર્ષે, Codex અને Sora બંનેને ઝડપથી અપનાવવામાં આવ્યા છે, અને વપરાશે ઝડપથી અમારી મૂળ અપેક્ષાથી આગળ ધકેલ્યું છે. અમે એક સતત પેટર્ન જોયું છે: વપરાશકર્તાઓ તેમાં ઊંડા ઉતરે છે, સાચું મૂલ્ય શોધે છે, અને પછી રેટ લિમિટ્સનો સામનો કરે છે.

રેટ લિમિટ્સ માંગને સમતોલ કરવામાં અને ન્યાયસંગત ઍક્સેસ સુનિશ્ચિત કરવામાં મદદ કરી શકે છે; પરંતુ જ્યારે વપરાશકર્તાઓને મૂલ્ય મળી રહ્યું હોય, ત્યારે કડક અટકનો સામનો કરવો નિરાશાજનક બની શકે છે. અમે એવો માર્ગ ઇચ્છતા હતા કે વપરાશકર્તાઓ આગળ ચાલુ રાખી શકે, અને સાથે સિસ્ટમ પ્રદર્શન અને અમારી પદ્ધતિ પ્રત્યેનો વપરાશકર્તા વિશ્વાસ પણ સુરક્ષિત રહે.

આ સમસ્યા ઉકેલવા માટે, અમે વપરાશ ગણતું રિયલ‑ટાઇમ ઍક્સેસ એન્જિન બનાવ્યું. તે એન્જિનના સ્તરોમાંનું એક સ્તર ક્રેડિટ્સ ખરીદવાની ક્ષમતા છે. જ્યારે વપરાશકર્તાઓ તેમની રેટ લિમિટ્સ વટાવે છે, ત્યારે ક્રેડિટ્સ તેમને તેમના ક્રેડિટ બેલેન્સમાંથી ખર્ચ કરીને અમારા પ્રોડક્ટ્સનો ઉપયોગ ચાલુ રાખવા દે છે.

તેની નીચે એક જ ઍક્સેસ મોડલમાં લિમિટ્સ, રિયલ‑ટાઇમ વપરાશ ટ્રેકિંગ અને ક્રેડિટ બેલેન્સને જોડતી જટિલ સિસ્ટમ છે. આ પોસ્ટમાં સમજાવવામાં આવે છે કે Codex અને Sora ને સ્કેલ કરવા માટે ઍક્સેસ કંટ્રોલ પર ફરી વિચારવું કેમ જરૂરી બન્યું, કેવી રીતે સાબિતીપણે યોગ્ય રિયલ‑ટાઇમ સિસ્ટમ દરેક વિનંતિ પર રેટ લિમિટ્સ અને ક્રેડિટ્સને ભેળવે છે, અને કેવી રીતે આ પાયા હવે બંને પ્રોડક્ટ્સ માટે વધારાની ઍક્સેસ ખુલ્લી કરે છે.

વિસ્તૃત દૃષ્ટિએ જોીએ તો, પરંપરાગત ઍક્સેસ મોડલ્સ ઘણી વખત પસંદગી માટે મજબૂર કરે છે:

• રેટ લિમિટ્સ શરૂઆતમાં મદદરૂપ બની શકે છે, પરંતુ ખૂટી જાય પછી વપરાશકર્તાઓને ખરાબ અનુભવ આપે છે: “પછી પાછા આવો.”
• વપરાશ‑આધારિત બિલિંગ લવચીક છે, પરંતુ વપરાશકર્તાઓને પ્રથમ ટોકનથી જ ચૂકવણી કરાવે છે—શરૂઆતના અન્વેષણને ટેકો આપવા માટે આ આદર્શ નથી.

Codex અને Sora માટે, બંનેમાંથી કોઈપણ એકલું પૂરતું નહોતું. જો અમે માત્ર રેટ લિમિટ્સ વધારીએ, તો માંગને સમતોલ રાખવા અને ન્યાયસંગતતા જાળવવા માટેના મહત્વપૂર્ણ નિયંત્રણો ગુમાવી દઈએ અને સૌને સેવા આપવા ક્ષમતા ખૂટી જાય. જો અમે સંપૂર્ણપણે અસિંક્રોનસ વપરાશ બિલિંગ પર નિર્ભર રહીએ, તો વિલંબ, ઓવરેજ અથવા રિકન્સિલિએશનની સમસ્યાઓ ઊભી થાય—ખાસ કરીને તે જ પ્રકારની સમસ્યાઓ, જે વપરાશકર્તાઓ સૌથી વધુ જોડાયેલા હોય ત્યારે તેમની નજરે ચડે છે.

તેના બદલે, અમને રિયલ‑ટાઇમ લિમિટ્સને pay-as-you-go ઍક્સેસ સાથે જોડતી એક હાઇબ્રિડ સિસ્ટમ જોઈએ હતી:

આ સિસ્ટમને નીચેના કામ કરવા જરૂરી હતા:

• રેટ લિમિટ્સ પહોંચે ત્યાં સુધી અમલમાં મૂકવી.
• એ જ વિનંતિમાં સરળતાથી ક્રેડિટ્સ પર પરિવર્તન કરવું.
• આ નિર્ણય રિયલ ટાઇમમાં લેવો.
• ક્રેડિટ વપરાશ ટ્રેક કરતી વખતે કડક રીતે ચોક્કસ અને ઑડિટ કરી શકાય તેવી હોવી.

અમણે કરેલા મુખ્ય ધારણાત્મક પરિવર્તનોમાંથી એક ઍક્સેસને ડિસિઝન વોટરફોલ તરીકે મોડલ કરવાનું હતું. “આને મંજૂરી છે?” એવું પૂછવાના બદલે, અમે પૂછીએ છીએ “કેટલું મંજૂર છે, અને ક્યાંથી?” વપરાશ ગણતી વખતે, સિસ્ટમ નીચેના ક્રમમાંથી પસાર થાય છે:

આ મોડલ દર્શાવે છે કે વપરાશકર્તાઓ પ્રોડક્ટનો અનુભવ વાસ્તવમાં કેવી રીતે કરે છે. રેટ લિમિટ્સ, ફ્રી ટિયર્સ, ક્રેડિટ્સ, પ્રમોશન્સ અને એન્ટરપ્રાઇઝ અધિકારો—આ બધું એક જ નિર્ણય સ્ટેકના સ્તરો છે. વપરાશકર્તાની દૃષ્ટિએ, તેઓ “સિસ્ટમ બદલે” નથી—તેઓ માત્ર Codex અને Sora નો ઉપયોગ ચાલુ રાખે છે. એટલા માટે ક્રેડિટ્સ અદૃશ્ય જેવી લાગે છે: તે વોટરફોલનું માત્ર એક વધુ ઘટક છે.

ક્રેડિટ વપરાશ હેન્ડલ કરવા માટે અમે તૃતીય‑પક્ષ વપરાશ બિલિંગ અને મીટરિંગ પ્લેટફોર્મ્સનું મૂલ્યાંકન કર્યું. તે ઇન્વોઇસિંગ અને રિપોર્ટિંગ માટે સારી રીતે યોગ્ય છે, પરંતુ બે અગત્યની આવશ્યકતાઓને પૂરી કરતી નહોતી:

જ્યારે વપરાશકર્તા કોઈ લિમિટ સુધી પહોંચે અને તેના પાસે ક્રેડિટ્સ ઉપલબ્ધ હોય, ત્યારે સિસ્ટમને તે તાત્કાલિક જાણવું જ જોઈએ. Best‑effort અથવા મોડું કાઉન્ટિંગ અચાનક બ્લોક્સ, અસંગત બેલેન્સ અને ખોટા ચાર્જ તરીકે સામે આવે છે. Codex અને Sora જેવી ઇન્ટરેક્ટિવ પ્રોડક્ટ્સ માટે, આવી નિષ્ફળતાઓ દેખાય પણ છે અને નિરાશાજનક પણ બને છે.

અમને દરેક પરિણામમાં પારદર્શિતા પણ આપવી હતી:

• વિનંતિને શા માટે મંજૂરી મળી અથવા રોકાઈ.
• તેમાં કેટલો વપરાશ થયો.
• કઈ લિમિટ્સ અથવા બેલેન્સ લાગુ પડ્યાં.

આ ક્ષમતાને અમારા નિર્ણય વોટરફોલમાં કડક રીતે એકીકૃત કરવાની જરૂર હતી; એને અલગ વપરાશ બિલિંગ પ્લેટફોર્મમાં એકલાં ઉકેલવાથી કામ નહોતું ચાલવાનું, કારણ કે એવું પ્લેટફોર્મ માત્ર બનતી ઘટનાનો એક ભાગ જ જોઈ શકતું. વપરાશકર્તાઓને વિશ્વાસ સાથે અમારા પ્રોડક્ટ્સ ઍક્સેસ કરવાની મંજૂરી આપવા માટે, અમને ચોકસાઈ, સમયબદ્ધતા અને અવલોકનીયતા પર સંપૂર્ણ નિયંત્રણ જોઈએ હતું. એ કારણથી અમે ઇન‑હાઉસ સોલ્યુશન તરફ વળ્યાં.

આને શક્તિ આપવા માટે, અમે સિંક્રોનસ ઍક્સેસ નિર્ણયો માટે ખાસ રચાયેલ વિતરિત વપરાશ અને બેલેન્સ સિસ્ટમ બનાવી.

ઉચ્ચ સ્તરે, સિસ્ટમ:

• દર વપરાશકર્તા અને દર ફીચર મુજબ વપરાશ ટ્રેક કરે છે.
• રેટ‑લિમિટ વિન્ડોઝ જાળવે છે.
• રિયલ‑ટાઇમ ક્રેડિટ બેલેન્સ જાળવે છે.
• સ્ટ્રીમિંગ અસિંક્રોનસ પ્રોસેસર દ્વારા બેલેન્સમાંથી idempotent રીતે ડેબિટ કરે છે.

દરેક વિનંતિ એક જ મૂલ્યાંકન માર્ગમાંથી પસાર થાય છે, જે રિયલ‑ટાઇમમાં નક્કી કરે છે કે કેટલો વપરાશ મંજૂર છે—રેટ લિમિટ્સમાંથી સિંક્રોનસ રીતે વપરાશ લઈ અને જરૂર પડે તો પૂરતા ક્રેડિટ્સ ચકાસી; ત્યારબાદ તે એક જ નિશ્ચિત પરિણામ આપે છે, જ્યારે કોઈપણ ક્રેડિટ ડેબિટ્સ અસિંક્રોનસ રીતે સેટલ થાય છે. આથી પ્રોડક્ટ્સમાં વર્તન સગત રહે છે અને ટીમોમાં ડુપ્લિકેટ લોજિક દૂર થાય છે.

આ સિસ્ટમના મુખ્ય ડિઝાઇન સિદ્ધાંતોમાંનું એક એ છે કે અમે અમારા બિલિંગની યોગ્યતા સાબિત કરી શકવી જોઈએ. આ અમારા ક્રેડિટ સપોર્ટની મૂળભૂત શરૂઆતને દર્શાવે છે, જે એન્ટરપ્રાઇઝ ગ્રાહકો સાથે શરૂ થઈ હતી. ઉપરના સિસ્ટમ ડાયાગ્રામમાં અમારી પાસે ત્રણ અલગ ડેટાસેટ્સ છે, જે એકબીજા સાથે જોડાયેલા છે:

• પ્રોડક્ટ વપરાશ ઇવેન્ટ્સ: વપરાશકર્તાએ હકીકતમાં શું કર્યું.
• મોનેટાઇઝેશન ઇવેન્ટ્સ: વપરાશ માટે અમે વપરાશકર્તાને શું ચાર્જ કરીએ છીએ.
• બેલેન્સ અપડેટ્સ: અમે વપરાશકર્તાના ક્રેડિટ બેલેન્સમાં કેટલો ફેરફાર કર્યો અને શા માટે.

આ ડેટાસેટ્સ ફક્ત ઉપઉત્પાદન નથી; હકીકતમાં તે જ સિસ્ટમને ચલાવે છે, જ્યાં દરેક ડેટાસેટ આગળના ડેટાસેટને ટ્રિગર કરે છે. શું બન્યું, તે સાથે જોડાયેલા કોઈપણ ચાર્જ, અને અમે શું ડેબિટ કર્યું તેને અલગ રાખવાથી અમે દરેક સ્તરને સ્વતંત્ર રીતે ઑડિટ, રીપ્લે અને રિકન્સાઇલ કરી શકીએ છીએ. આ એક જાગૃત trade-off છે, જ્યાં અમે સાબિતીપણે યોગ્યતાને પ્રાથમિકતા આપીએ છીએ, ભલે તેના કારણે ક્રેડિટ બેલેન્સ અપડેટ્સ થોડા મોડા થાય. અમે આ કેવી રીતે હાંસલ કર્યું:

• પ્રોડક્ટ વપરાશ ઇવેન્ટ્સ બધા વપરાશકર્તા પ્રવૃત્તિ માટે પ્રકાશિત થાય છે, ભલે તે ક્રેડિટ વપરાશને ચલાવે કે ન ચલાવે. આ વપરાશકર્તા પ્રવૃત્તિ માટે ઑડિટ ટ્રેઇલ આપે છે અને અમે ક્રેડિટ્સ શા માટે ચાર્જ કર્યા અથવા શા માટે ન કર્યા તે સમજાવવા દે છે.
• દરેક ઇવેન્ટમાં સ્થિર idempotency key હોય છે, જેથી retries, replays અથવા worker restarts ક્યારેય બેલેન્સને double‑debit કરી શકતા નથી, જે double‑charging અટકાવે છે. આ અમને ઑફલાઇન અમારા કામની ચકાસણી માટે batch reconciliation ચલાવવા પણ દે છે.
• ઑડિટ ટ્રેઇલ બનાવવા માટે અમે synchronous updates ની જગ્યાએ asynchronous (પણ હજુ પણ near-real-time) બેલેન્સ અપડેટ્સ કરીએ છીએ. અમે વપરાશકર્તાના બેલેન્સને અપડેટ કરવામાં થતો નાનો વિલંબ સ્વીકારીએ છીએ જેથી અમે સાબિત કરી શકીએ કે સિસ્ટમ યોગ્ય રીતે કાર્ય કરી રહી છે અને અમારા વપરાશકર્તાઓને વિશ્વાસ અપાવી શકીએ કે અમે તેમને ખોટું બિલિંગ કરતા નથી. જ્યારે આ ટૂંકા વિલંબને કારણે અમે વપરાશકર્તાના ક્રેડિટ બેલેન્સથી વધુ વાપરી જઈએ, ત્યારે અમે આપમેળે રિફંડ કરીએ છીએ; કડક અમલીકરણ કરતાં અમે સાબિતીપણે યોગ્યતા અને વપરાશકર્તા વિશ્વાસને પસંદ કરીએ છીએ.
• અમે Credit Balance ઘટાડીએ છીએ અને એક જ atomic database transaction માં Balance Update રેકોર્ડ દાખલ કરીએ છીએ. પ્રતિ એકાઉન્ટ બેલેન્સ અપડેટ્સ serialise થાય છે, તેથી સમકાલીન વિનંતીઓ ક્યારેય તે જ ક્રેડિટ્સ ખર્ચવા માટે race કરી શકતી નથી. Balance Update રેકોર્ડમાં ડેબિટ રકમ સાથે તે અપડેટને ટ્રિગર કરનાર monetization event સુધીનું attribution પણ હોય છે; આ બધું એક જ database transaction માં બાંધવાથી અમને ક્રેડિટ બેલેન્સના દરેક ફેરફાર માટે ઑડિટ ટ્રેઇલ મળવાની ખાતરી રહે છે.

આ સમગ્ર કડકતા એક જ હેતુને ટેકો આપે છે: ઍક્સેસને સરળ અને સુરક્ષિત બનાવવી. જ્યારે લોકો સર્જન કરે છે અથવા કોડ લખે છે, ત્યારે તેમને આ વિચારવાની જરૂર ન હોવી જોઈએ કે વિનંતિ પસાર થશે કે નહીં, તેમને વધુ ચાર્જ થશે કે નહીં, અથવા તેમનું બેલેન્સ સાચું છે કે નહીં. વપરાશ, બિલિંગ અને બેલેન્સને સાબિતીપણે યોગ્ય બનાવીને, અમે વપરાશકર્તાઓને એવી સિસ્ટમ આપીએ છીએ જે તેમના અનુભવથી ધ્યાન ભંગ કરતી નથી. એ જ અમને કડક અટકોને સતત ઍક્સેસથી બદલવા દે છે—અને એ જ ક્રેડિટ્સને વાસ્તવિક કામની વચ્ચે ઉપયોગી બનાવે છે, માત્ર ઇન્વોઇસ પર નહીં.

અમારા અભિગમ પાછળનો માર્ગદર્શક સિદ્ધાંત વપરાશકર્તાની ગતિને સુરક્ષિત રાખવાનો છે. દરેક આર્કિટેક્ચરલ નિર્ણય વપરાશકર્તા‑મુખી પરિણામ સાથે નકશાય છે: રિયલ‑ટાઇમ બેલેન્સ અનાવશ્યક વિક્ષેપોને રોકે છે, atomic consumption double-charging અટકાવે છે, અને એકીકૃત ઍક્સેસ લોજિક અનુમાન કરી શકાય તેવું વર્તન સુનિશ્ચિત કરે છે. પરિણામે લોકો વધુ સમય કામ કરી શકે છે, વધુ ઊંડાણથી શોધખોળ કરી શકે છે અને કડક અટકો અથવા સમય પહેલાં પ્લાન બદલ્યા વિના પ્રોજેક્ટ્સને આગળ લઈ જઈ શકે છે.

જ્યારે વપરાશકર્તાઓ જોડાયેલા હોય, ત્યારે સિસ્ટમએ તેમને આગળ વધવામાં મદદ કરવી જોઈએ, રસ્તામાં આવવું નહીં. લિમિટ્સ અને ક્રેડિટ્સ પૃષ્ઠભૂમિમાં વિલીન થઈ જાય છે.

એવો અનુભવ બનાવવા માટે ઍક્સેસ, વપરાશ અને બિલિંગને એક જ સિસ્ટમ તરીકે ફરી વિચારવાની અને એવી ઇન્ફ્રાસ્ટ્રક્ચર બનાવવાની જરૂર પડી કે જે યોગ્યતાને first‑class product feature તરીકે ગણે. સમય જતાં એ જ પાયો વધુ પ્રોડક્ટ્સ સુધી વિસ્તરી શકે છે; Codex અને Sora તો માત્ર શરૂઆત છે.