Utover begrenset hastighet: utvidelse tilgang til Codex og Sora

I løpet av det siste året har både Codex og Sora opplevd rask introduksjon, og bruken har raskt overgått det vi opprinnelig forventet. Vi har sett et konsekvent mønster: brukere kaster seg ut i det, finner reell verdi, og støter deretter på bruksgrenser.

Begrensninger på forespørselsrate kan bidra til å jevne ut etterspørselen og sikre rettferdig tilgang. Men når brukerne opplever nytteverdi, kan det være frustrerende å møte på en vegg. Vi ønsket en måte for brukerne å fortsette på, samtidig som vi beskyttet systemytelsen og brukernes tillit til vår tilnærming.

For å løse dette bygde vi en tilgangsmotor i sanntid, som teller bruk. Ett av lagene i den motoren er muligheten til å kjøpe kreditter. Når brukere overskrider sine grenseverdier, kan de bruke kreditter for å fortsette å bruke produktene våre ved å redusere kredittsaldoen sin.

Under dette ligger et komplekst system som fusjonerer begrensninger, sanntidssporing av bruk og kredittsaldoer i én enkelt tilgangsmodell. Dette innlegget forklarer hvorfor skalering av Codex og Sora krevde nytenkning av tilgangskontroll, hvordan et beviselig korrekt sanntidssystem kombinerer ratebegrensninger og kreditter per forespørsel, og hvordan dette fundamentet nå åpner for mer tilgang for begge produktene.

Når vi zoomer ut, har tradisjonelle tilgangsmodeller tendens til å tvinge frem et valg:

• Begrensninger i bruk kan være nyttige i starten, men gir brukerne en dårlig opplevelse når de når grensen: «kom tilbake senere».
• Bruksbasert fakturering er fleksibel, men gjør at brukerne betaler fra første token—ikke ideelt for å støtte tidlig utforskning.

For Codex og Sora var ingen av dem tilstrekkelige på egen hånd. Hvis vi bare økte bruksgrensene, ville vi miste viktige kontroller for å jevne ut etterspørselen og oppnå rettferdighet, og vi ville gå tom for kapasitet til å betjene alle. Hvis vi stolte helt på asynkron bruksfakturering, ville det medføre forsinkelser, overskridelser eller avstemmingsproblemer—akkurat den typen problemer brukerne legger merke til når de er mest engasjert.

Det vi trengte i stedet var et enkelt hybridsystem som kombinerte sanntidsgrenser med pay-as-you-go-tilgang:

Dette systemet måtte:

• Håndhev hastighetsgrenser inntil de er nådd.
• Overgang til kreditter sømløst i samme forespørsel.
• Ta den avgjørelsen i sanntid
• Vær nøye og sørge for at det kan revideres når du sporer kredittforbruket.

En av de viktigste konseptuelle endringene vi gjorde, var å modellere tilgang som en beslutningskaskade. I stedet for å spørre «er dette tillatt?», spør vi, «hvor mye er tillatt, og hvorfra?». Når systemet teller bruken, går det gjennom følgende sekvens:

Denne modellen avspeiler hvordan brukere faktisk opplever produktet. Bruksgrenser, gratisnivåer, kreditter, kampanjer og bedriftsrettigheter er alle bare lag i den samme beslutningsstabelen. Fra en brukers perspektiv bytter de ikke systemer—de fortsetter bare å bruke Codex og Sora. Derfor føles det som om krediteringer usynlige: de er bare enda et annet element i fossen.

Vi evaluerte tredjepartsplattformer for fakturering og måling av bruk for å håndtere kredittforbruk. De er godt egnet for fakturering og rapportering, men det er to kritiske krav de ikke oppfyller:

Når en bruker når en grense og har kreditter tilgjengelig, må systemet vite det umiddelbart. Best‑effort- eller forsinket telling vises som overraskende blokkeringer, inkonsistente saldoer og feilaktige belastninger. For interaktive produkter som Codex og Sora, blir disse feilene synlige og frustrerende.

Vi måtte også tilby åpenhet i hvert utfall:

• Hvorfor en forespørsel ble tillatt eller blokkert.
• Hvor mye bruk ble anvendt
• Hvilke grenser eller balanser ble brukt

Denne funksjonaliteten måtte integreres tett i vår beslutningsprosess, i stedet for å bli løst isolert i en separat plattform for bruksfakturering som bare så en del av det som foregikk. For å gi brukerne tilgang til produktene våre uten å gå på kompromiss med tilliten, måtte vi ha full kontroll over korrekthet, timing og observerbarhet. Det presset oss mot en intern løsning.

For å åpne dette, bygde vi et distribuert bruks- og balansesystem som er utviklet spesielt for synkrone tilgangsbeslutninger.

På et overordnet nivå sørger systemet for å:

• spore bruk per bruker, per funksjon,
• opprettholde bruksgrensevinduer,
• opprettholde kredittsaldoer i sanntid,
• debitere saldoer idempotent gjennom en strømmende asynkron prosessor.

Hver forespørsel går gjennom en enkelt evalueringsbane som tar en sanntidsbeslutning om hvor mye bruk som er tillatt ved å synkront forbruke fra hastighetsgrenser og, om nødvendig, verifisere tilstrekkelige kreditter; deretter returnerer den ett endelig utfall mens eventuelle kredittbelastninger avregnes asynkront. Dette sikrer konsekvent atferd på tvers av produkter og eliminerer duplisert logikk på tvers av team.

Et av de viktigste designprinsippene for dette systemet er at vi må kunne bevise at faktureringen vår er korrekt. Dette gjenspeiler røttene til vår kredittstøtte, som oppsto med bedriftskunder. I systemdiagrammet ovenfor har vi tre separate datasett, som alle er knyttet sammen:

• Hendelser for produktbruk: Hva brukeren faktisk gjorde
• Inntektsgenererende hendelser: Hva vi krever av brukeren for deres bruk
• Saldooppdateringer: Hvor mye vi har justert brukerens kredittsaldo og hvorfor

Disse datasettene er ikke et tilfeldig biprodukt; de driver faktisk systemet, hvor hvert datasett utløser det neste. Når vi skiller hva som skjedde, eventuelle tilknyttede gebyrer og hva vi belastet, lar oss uavhengig revidere, spille av på nytt og avstemme hvert lag. Dette er et bevisst kompromiss der vi prioriterer bevisbar korrekthet, på bekostning av at oppdateringer av kredittsaldoen blir noe forsinket. Hvordan vi oppnådde dette:

• Hendelser for produktbruk publiseres for all brukeraktivitet, enten det fører til kredittforbruk eller ikke. Dette gir et revisjonsspor for brukeraktivitet og lar oss forklare hvorfor vi belastet kreditter eller ikke.
• Hver hendelse har en stabil idempotensnøkkel, slik at nye forsøk, gjentatte avspillinger eller omstarter av arbeidere aldri kan føre til dobbel belastning av en saldo, noe som forhindrer dobbel belastning. Dette lar oss også kjøre en batchavstemming for å verifisere arbeidet vårt offline.
• Vi utfører asynkrone (men fortsatt nesten i sanntid) saldooppdateringer i stedet for synkrone oppdateringer for å lage et revisjonsspor. Vi tolererer en liten forsinkelse i oppdateringen av brukerens saldo for å bevise at systemet fungerer og forsikre brukerne våre om at vi ikke feilfakturerer dem. Når den korte forsinkelsen gjør at vi overskrider en brukers kredittsaldo, refunderer vi automatisk. Vi velger beviselig korrekthet og brukertillit fremfor streng håndheving.
• Vi reduserer Kredittsaldoen og setter inn en Saldooppdatering i én enkelt atomisk databasetransaksjon. Saldooppdateringer serialiseres per konto, slik at samtidige forespørsler aldri kan konkurrere om å bruke de samme kredittene. Posten Balanseoppdatering inneholder både debetbeløpet og attribusjon tilbake til inntektsgenereringshendelsen som utløste oppdateringen; når vi pakker dette inn i én enkelt databasetransaksjon, garanterer at vi har et revisjonsspor for hver justering av kredittsaldoen.

All denne grundigheten støtter ett mål: å gjøre tilgangen enkel og trygg. Når folk skaper eller koder, skal de ikke måtte lure på om en forespørsel vil gå gjennom, om de vil bli overbelastet, eller om saldoen deres er korrekt. Ved å gjøre bruk, fakturering og saldoer beviselig korrekte, gir vi brukerne et system som ikke distraherer fra opplevelsen deres. Det er det som lar oss erstatte det å støte på en vegg, med kontinuerlig tilgang—og det er det som gjør kreditter anvendelige midt i virkelig arbeid, ikke bare på en faktura.

Det styrende prinsippet bak vår tilnærming er å beskytte brukerens fremdrift. Hver arkitektonisk beslutning kan spores tilbake til et brukerrettet utfall: sanntidssaldoer forhindrer unødvendige avbrudd, atomforbruk forhindrer dobbeltbelastning, og enhetlig tilgangslogikk sikrer forutsigbar atferd. Resultatet er at folk kan jobbe lenger, utforske mer i dybden, og ta prosjekter videre uten å møte harde stopp eller for tidlige endringer i planene.

Når brukere er engasjert, bør systemet hjelpe dem til å fortsette, ikke hindre dem. Grenser og kreditter forsvinner i bakgrunnen.

Det å bygge den opplevelsen krevde nytenkning rundt tilgang, bruk og fakturering som ett enkelt system og bygge infrastruktur som behandler korrekthet som en førsteklasses produktfunksjon. Det samme grunnlaget kan utvides til flere produkter over tid; Codex og Sora er bare begynnelsen.