Higit sa limit ng rate: pinalalawak ang access sa Codex at Sora

Noong nakaraang taon, nakaranas ng napakabilis na pag-adopt ang Codex at Sora, kung saan mas mabilis kaysa sa aming orihinal na inaasahan ang paggamit. Nakakita kami ng pare-parehong pattern: gagamitin ng mga user, hahanap ng tunay na halaga, at pagkatapos ay makakasagupa ng mga limitasyon sa rate.

Makakatulong ang mga limitasyon sa rate na pinuhin ang pangangailangan at matiyak ang patas na access; gayunpaman, kapag nakakakuha ng halaga ang mga user, maaaring maging nakakainis ang biglang paghinto. Gusto naming magkaroon ng paraan para makapagpatuloy ang mga user, habang pinoprotektahan ang pagganap ng sistema at ang tiwala ng mga user sa aming pamamaraan.

Upang malutas ito, bumuo kami ng real‑time na access engine na bumibilang ng paggamit. Isa sa mga layer ng engine na iyon ay ang kakayahang bumili ng mga credit. Kapag lumampas ang mga user sa kanilang mga limitasyon sa rate, pinapayagan sila ng mga credit na ipagpatuloy ang paggamit ng aming mga produkto sa pamamagitan ng pagbabawas sa kanilang balanse ng credit.

Sa ilalim nito ay may kumplikadong sistema na pinagsasama ang mga limitasyon, pagsubaybay sa paggamit sa real-time, at mga balanse ng credit sa iisang modelo ng pag-access. Tinalakay ng post na ito kung bakit ang pagpapalawak sa Codex at Sora ay nangangailangan ng muling pag-isip sa mga kontrol sa access, kung paano pinagsasama ng napatunayang tama, real-time na sistema ang mga limitasyon sa rate at mga kredito sa bawat kahilingan, at kung paano ang pundasyong iyon ay nagbubukas ng karagdagang pag-access para sa parehong mga produkto.

Kung titingnan sa mas malawak na perspektibo, karaniwang pinipilit ng mga tradisyunal na modelo ng access ang pagpipilian:

• Ang mga limitasyon sa rate ay maaaring makatulong sa simula, pero nag-iiwan sa mga user ng masamang karanasan kapag naubos na ang mga ito: “bumalik na lang mamaya”
• Ang pagsingilna ‑batay sa paggamit ay naiaangkop, ngunit pinagbabayad ang mga user mula sa unang token—hindi ito mainam para sa pagsuporta sa maagang pagtuklas

Para sa Codex at Sora, hindi sapat ang alinman sa dalawa ang mag-isa. Kung basta na lang naming itinaas ang mga limitasyon sa rate, mawawala sa amin ang mahahalagang kontrol sa pagpino ng pangangailangan at pagiging patas, at mauubusan kami ng kapasidad para mapagsilbihan ang lahat. Kung lubos kaming nasa sa asynchronous na pagsingil batay sa paggamit, magdudulot ito ng pagkaantala, mga labis na singil, o mga isyu sa reconciliation—eksaktong mga uri ng problemang napapansin ng mga user tuwing pinakaaktibo sila.

Sa halip, ang kinailangan namin ay isang iisang hybrid na sistema na pinagsasama ang mga limitasyon sa real-time at access na pay-as-you-go:

Kinailangan ng sistema na:

• Ipatupad ang mga limitasyon sa rate hanggang sa maabot ang mga ito
• Maayos na lumipat sa mga kredito sa loob ng parehong kahilingan
• Gumawa ng desisyon sa real-time
• Maging tumpak sa detalye at nao-audit kapag sinusubaybayan ang pagkonsumo ng kredito

Isa sa mga pangunahing konseptwal na pagbabagong ginawa namin ay ang pagmomodelo ng access bilangdecision waterfall. Sa halip na magtanong ng “pinapayagan ba ito?”, ang tinatanong namin ay, “hanggang magkano ang pinapayagan at mula saan?” Kapag binibilang ang paggamit, dumadaan ang sistema sa pagkakasunod-sunod na ito:

Ang modelong ito ay sumasalamin sa kung paano talaga nararanasan ng mga user ang produkto. Ang mga limitasyon sa rate, mga libreng tier, mga kredito, mga promosyon, at mga karapatan para sa enterprise ay pawang mga layer lang sa iisang decision stack. Mula sa pananaw ng user, hindi sila “nagpapalit ng mga sistema”—patuloy lang nilang ginagamit ang Codex at Sora. Iyon ang dahilan kung bakit parang hindi nakikita ang mga kredito: isa lang silang elemento sa waterfall.

Sinuri namin ang mga third-party na platform para sa pagsingil at pagmetro ng paggamit upang pamahalaan ang pagkonsumo ng kredito. Angkop ang mga ito para sa pag-invoice at pag-uulat, ngunit hindi natugunan ang dalawang kritikal na pangangailangan:

Kapag naabot ng user ang limitasyon at may magagamit na mga kredito, dapat malaman ito ng sistema kaagad. Ang best-effort o naantalang pagbibilang ay nagreresulta sa mga nakakagulat na harang, hindi pare-parehong balanse, at maling singil. Para sa mga produktong interaktibo na tulad ng Codex at Sora, nagiging lantad at nakakadismaya ang mga pagkabigong iyon.

Kinailangan din naming mag-alok ng transparency sa bawat resulta:

• Bakit pinahintulutan o hinarangan ang isang kahilingan
• Gaano karaming paggamit ang nagamit nito
• Aling mga limitasyon o balanse ang inilapat

Kinailangan na mahigpit na maisama ang kakayahang ito sa aming decision waterfall sa halip na lutasin ito nang hiwalay sa magkahiwalay na platform ng pagsingil batay sa paggamit na iisang bahagi lamang ng nangyayari ang nakikita. Upang pahintulutan ang mga user na ma-access ang aming mga produkto nang hindi sinasakripisyo ang tiwala, kailangan naming magkaroon ng ganap na kontrol sa kawastuhan, oras, at pagmamasid. Tinulak kami nito patungo sa solusyong in-house.

Upang mapagana ito, bumuo kami ng ipinamamahaging sistema ng paggamit at balanse na dinisenyo partikular para sa mga sabayang desisyon sa pag-access.

Sa mataas na antas, ang ginagawa ng sistema ay:

• Sinusubaybayan ang paggamit ng bawat user, bawat tampok
• Pinapanatili ang mga puwang ng limitasyon sa rate
• Pinananatili ang mga balanse ng kredito sa real-time
• Nagde-debit ng mga balanse nang paulit-ulit sa pamamagitan ng streaming na async processor

Dumadaan ang bawat kahilingan sa landas ng pagsusuri na gumagawa ng desisyon sa real-time kung gaano karaming paggamit ang pinapayagan sa pamamagitan ng sabayang pagkonsumo mula sa mga limitasyon sa rate at, kung kinakailangan, pagbeberipika ng sapat na mga kredito; pagkatapos ay nagbabalik ito ng isang na kinalabasan habang inaayos ang anumang mga debit sa kredito sa asynchronous na paraan. Tinitiyak nito ang pare-parehong gawi sa lahat ng produkto at inaalis ang nadodobleng lohika sa lahat ng team.

Isa sa mga pangunahing prinsipyo ng disenyo ng sistemang ito ay dapat naming mapatunayan na tama ang aming pagsingil. Ipinapakita nito ang mga ugat ng aming suporta sa kredito, na nagmula sa mga customer ng enterprise. Sa diagram ng sistema sa itaas, mayroon tayong tatlong magkakahiwalay na dataset na magkakaugnay:

• Mga kaganapan sa paggamit ng produkto: Ang aktwal na ginawa ng user
• Mga kaganapan sa monetization: Ang sinisingil namin sa user para sa kanilang paggamit
• Mga update sa balanse: Gaano kalaki ang in-adjust namin sa balanse ng kredito ng user at bakit

Ang mga dataset na ito ay hindi simpleng resulta; sila ang nagpapatakbo ng sistema, kung saan ang bawat dataset ay nag-uudyok sa susunod. Ang paghihiwalay sa mga nangyari, ang anumang kaugnay na singil, at mga na-debit namin ay nagbibigay-daan sa amin na magsagawa ng independiyenteng pag-audit, pag-replay, at pag-reconcile sa bawat layer. Isa itong sinadyang kapalit kung saan inuuna namin ang mapapatunayang kawastuhan, kapalit ng bahagyang pagkaantala ng mga update sa balanse ng kredito. Paano namin ito naisakatuparan:

• Ang mga kaganapan sa paggamit ng produkto ay inilalathala para sa lahat ng aktibidad ng user, nagdudulot man ito ng pagkonsumo ng kredito o hindi. Nagbibigay ito ng bakas ng pag-audit para sa aktibidad ng user at nagbibigay-daan sa amin na ipaliwanag kung bakit kami naningil, o hindi naningil, ng mga kredito.
• Ang bawat kaganapan ay may dalang matatag susi sa pagiging paulit-ulit, kaya't ang mga pagsubok muli, pag-ulit, o pag-restart ng manggagawa ay hindi kailanman makakapag-double-debit ng balanse, na pumipigil sa dobleng pagsingil. Binibigyang-daan din kami nitong magsagawa ng batch reconciliation upang beripikahin ang aming trabaho offline.
• Gumagawa kami ng mga asynchronous (ngunit malapit pa rin sa real-time) na update sa balanse sa halip na mga synchronous na update upang makabuo ng bakas ng pag-audit. Pinapayagan namin ang kaunting pagkaantala sa pag-update ng balanse ng user upang mapatunayan na gumagana ang sistema at matiyak sa aming mga user na hindi namin sila sinisingil nang mali. Kapag ang maikling pagkaantala na iyon ay nagiging sanhi na masobrahan namin ang balanse ng kredito ng user, awtomatiko namin itong nire-refund; mas pinipili namin ang mapapatunayang kawastuhan at tiwala ng user kaysa sa mahigpit na pagpapatupad.
• Binabawasan namin ang Balanse ng Kredito at naglalagay ng tala ng Update ng Balanse sa iisang atomic na transaksyon sa database. Ang mga pag-update ng balanse ay isinasagawa nang sunod-sunod para sa bawat account, kaya't hindi kailanman mag-uunahan ang sabay-sabay na kahilingan sa paggastos ng parehong kredito. Ang tala ng Update ng Balanse ay naglalaman ng parehong halaga ng debit pati na rin ng atribusyon pabalik sa monetization event na nag-trigger ng update; ginagarantiya ng pag-embed nito sa iisang transaksyon ng database na mayroon tayong bakas ng pag-audit para sa bawat pagbabago sa balanse ng kredito.

Ang lahat ng mahigpit na pagsunod na ito ay sumusuporta sa isang layunin: gawing simple at ligtas ang pag-access. Kapag gumagawa o nagko-code ang mga tao, hindi nila kailangang mag-alala kung ang kahilingan ay matutuloy, kung masisingil sila nang sobra, o kung tama ang kanilang balanse. Sa pamamagitan ng pagtiyak na tama ang paggamit, pagsingil, at mga balanse, binibigyan namin ang mga user ng sistema na hindi nakakaabala sa kanilang karanasan. Iyan ang dahilan kung bakit napapalitan namin ang mga pagtatapos ng tuloy-tuloy na access—at iyan din ang dahilan kung bakit nagiging magagamit ang mga kredito sa gitna ng aktwal na trabaho, hindi lamang sa invoice.

Ang prinsipyong gumagabay sa aming pamamaraan ay ang pagprotekta sa momentum ng user. Ang bawat desisyong pang-arkitektura ay bumabalik sa resultang nakikita ng user: ang mga balanse sa real-time ay pumipigil sa mga hindi kinakailangang pagkagambala, ang atomic na pagkonsumo ay pumipigil sa dobleng pagsingil, at natitiyak ng pinag-isang lohika ng access ang mahuhulaang gawi. Ang resulta ay maaaring magtrabaho ang mga tao nang mas matagal, tumuklas nang mas malalim, at mas paunlarin ang mga proyekto nang hindi kailangang humarap sa biglaang pagtatapos o maagang pagbabago ng plano.

Kapag abala ang mga user, dapat tulungan sila ng sistema na magpatuloy, hindi maging sagabal. Naglalaho sa likuran ng eksena ang mga limitasyon at kredito.

Ang pagbuo ng karanasang iyon ay nangailangan ng muling pag-iisip sa access, paggamit, at pagsingil bilang iisang sistema at pagbuo ng imprastraktura na tumuturing sa kawastuhan bilang pangunahing tampok ng produkto. Maaaring mapalawak ang parehong pundasyon sa mas maraming produkto sa pagdaan ng panahon; simula pa lamang ang Codex at Sora.