Yli käyttörajoitusten: Codexin ja Soran käytön skaalaaminen

Viime vuoden aikana sekä Codex että Sora ovat yleistyneet nopeasti, ja niiden käyttö on ylittänyt odotuksemme. Olemme havainneet johdonmukaisen kaavan: käyttäjät sukeltavat sisään, löytävät todellista arvoa ja törmäävät sitten käyttörajoituksiin.

Käyttörajoitukset voivat auttaa tasoittamaan kysyntää ja varmistamaan reilun pääsyn; kun käyttäjät saavat arvoa, äkillinen pysäytys voi kuitenkin olla turhauttavaa. Halusimme löytää tavan, jolla käyttäjät voivat jatkaa toimintaansa, samalla kun varmistamme järjestelmän suorituskyvyn ja käyttäjien luottamuksen lähestymistapaamme.

Ratkaistaksemme tämän rakensimme reaaliaikaisen käyttömoottorin, joka laskee käyttöä. Yksi tämän moottorin kerroksista on mahdollisuus ostaa krediittejä. Kun käyttäjät ylittävät käyttörajoituksensa, he voivat jatkaa tuotteidemme käyttöä krediittisaldoaan kuluttamalla.

Tämän alla on monimutkainen järjestelmä, joka yhdistää rajoitukset, reaaliaikaisen käytön seurannan ja luottosaldot yhteen käyttöoikeusmalliin. Tässä julkaisussa käsitellään sitä, miksi Codexin ja Soran skaalaaminen vaati käyttöoikeuksien hallinnan uudelleenarviointia, miten todistettavasti oikea, reaaliaikainen järjestelmä yhdistää käyttörajoitukset ja krediitit pyyntöä kohden, ja miten tämä perusta avaa nyt lisäkäyttömahdollisuuksia molemmille tuotteille.

Kun tarkastellaan suurempaa kuvaa, perinteiset käyttöoikeusmallit pakottavat usein valitsemaan:

• Käyttörajoitukset voivat aluksi olla hyödyllisiä, mutta ne jättävät käyttäjille huonon kokemuksen, kun ne loppuvat: "palaa takaisin myöhemmin"
• Käyttöperusteinen laskutus on joustavaa, mutta käyttäjät maksavat ensimmäisestä tokenista alkaen—ei ihanteellista varhaisen kokeilun tukemiseen

Codexille ja Soralle kumpikaan ei ollut riittävä yksinään. Jos yksinkertaisesti nostaisimme käyttörajoituksia, menettäisimme tärkeät kysynnän tasoittamiseen ja oikeudenmukaisuuteen liittyvät hallintakeinot ja kapasiteetti kaikkien palvelemiseen loppuisi. Jos luottaisimme täysin asynkroniseen käytön mukaiseen laskutukseen, aiheuttaisimme viivettä, ylityksiä tai täsmäytysongelmia—juuri sellaisia ongelmia, jotka käyttäjät huomaavat, kun he ovat kaikkein sitoutuneimpia.

Sen sijaan tarvitsimme yhden hybridijärjestelmän, joka yhdistää reaaliaikaiset rajoitukset ja veloituksen käytön mukaan:

Tämän järjestelmän täytyi:

• Valvo käyttörajoituksia kunnes ne saavutetaan
• Siirry saumattomasti krediitteihin saman pyynnön yhteydessä
• Tehdä päätös reaaliajassa
• Olla tarkka ja varmista, että seuranta on tarkastettavissa, kun krediittien käyttöä seurataan

Yksi keskeisistä käsitteellisistä muutoksista oli käyttöoikeuden mallintaminen päätöksenteon vesiputouksena. Sen sijaan, että kysyisimme "onko tämä sallittua?", kysymme, "kuinka paljon on sallittua ja mistä?" Kun käyttöä lasketaan, järjestelmä käy läpi seuraavan sekvenssin:

Tämä malli kuvastaa sitä, miten käyttäjät kokevat tuotteen todellisuudessa. Käyttörajat, ilmaiset tasot, krediitit, kampanjat ja yritysoikeudet ovat kaikki vain kerroksia samassa päätöspinossa. Käyttäjän näkökulmasta he eivät "vaihda järjestelmiä" – he vain jatkavat Codexin ja Soran käyttöä. Siksi krediitit tuntuvat näkymättömiltä: ne ovat vain yksi elementti muiden joukossa vesiputouksessa.

Arvioimme kolmannen osapuolen laskutus- ja mittausalustoja krediittien kulutuksen hallitsemiseksi. Ne sopivat hyvin laskutukseen ja raportointiin, mutta eivät täyttäneet kahta keskeistä vaatimusta:

Kun käyttäjä saavuttaa rajan ja hänellä on krediittejä käytettävissä, järjestelmän on tiedettävä siitä välittömästi. Parhaan yrityksen tai viivästyneen laskennan tulokset näkyvät yllätyksellisinä lohkoina, epäjohdonmukaisina saldoina ja virheellisinä veloituksina. Interaktiivisten tuotteiden, kuten Codexin ja Sora kohdalla, näistä vioista tulee näkyviä ja turhauttavia.

Meidän piti myös tarjota läpinäkyvyyttä jokaiseen lopputulokseen:

• Miksi pyyntö hyväksyttiin tai estettiin
• Kuinka paljon käyttöä kului
• Mitä rajoja tai saldoja sovellettiin

Tämä ominaisuus piti integroida päätöksentekoprosessiimme tiiviisti sen sijaan, että se olisi ratkaistu erillään erillisessä käytön laskutusalustassa, joka näkisi vain yhden osan tapahtumista. Jotta käyttäjät voivat käyttää tuotteitamme luottamusta vaarantamatta, tarvitsimme kattavan oikeellisuuden, ajoituksen ja havainnoitavuuden hallinnan. Se sai meidät valitsemaan sisäisen ratkaisun.

Tämän mahdollistamiseksi loimme hajautetun käyttö- ja saldohallintajärjestelmän, joka on suunniteltu erityisesti synkronisia käyttöoikeuspäätöksiä varten.

Ylemmällä tasolla järjestelmä:

• Seuraa tapahtuvaa käyttöä käyttäjäkohtaisesti ja ominaisuuskohtaisesti
• Ylläpitää käyttörajaikkunoita
• Ylläpitää reaaliaikaisia krediittisaldoja
• Veloittaa saldot idempotentisti suoratoistavan asynkroniprosessorin avulla

Jokainen pyyntö kulkee yhden arviointipolun läpi, joka tekee reaaliaikaisen päätöksen siitä, kuinka paljon käyttöä sallitaan kuluttamalla käyttörajoista synkronisesti ja tarvittaessa varmistamalla riittävät krediitit; se palauttaa sitten yhden lopullisen tuloksen samalla, kun se selvittää mahdolliset krediittiveloitukset asynkronisesti. Tämä varmistaa johdonmukaisen toiminnan tuotteiden välillä ja poistaa päällekkäisen logiikan tiimien kesken.

Yksi tämän järjestelmän keskeisistä suunnitteluperiaatteista on, että meidän on pystyttävä todistamaan laskutuksemme oikeellisuus. Tämä heijastaa luottotukemme juuria, jotka saivat alkunsa yritysasiakkaista. Yllä olevassa järjestelmäkaaviossa on kolme erillistä tietojoukkoa, jotka kaikki liittyvät toisiinsa:

• Tuotteen käyttötapahtumat: Mitä käyttäjä itse asiassa teki
• Kaupallistamistapahtumat: Mitä veloitamme käyttäjältä käytöstä
• Saldopäivitykset: Kuinka paljon muutimme käyttäjän luottosaldoa ja miksi

Nämä tietojoukot eivät ole satunnainen sivutuote; ne todella ohjaavat järjestelmää, ja kukin tietojoukko käynnistää seuraavan. Erottamalla tapahtuneen, siihen liittyvät veloitukset ja veloittamamme summan voimme itsenäisesti auditoida, toistaa ja täsmäyttää kunkin kerroksen. Tämä on tietoinen kompromissi, jossa asetamme etusijalle todennettavan oikeellisuuden, vaikka se tarkoittaa, että krediittisaldon päivitykset viivästyvät hieman. Kuinka saavutimme tämän:

• Tuotteen käyttöön liittyvät tapahtumat julkaistaan kaikesta käyttäjätoiminnasta, riippumatta siitä, aiheuttaako se krediittien kulutusta vai ei. Tämä tarjoaa käyttäjätoiminnan seurantaketjun ja antaa meille mahdollisuuden selittää, miksi veloitimme tai emme veloittaneet krediittejä.
• Kullakin tapahtumalla on vakaa idempotenssiavain, joten uudelleenyritykset, toistot tai työntekijäprosessin uudelleenkäynnistykset eivät voi koskaan veloittaa saldoa kahdesti, mikä estää kaksinkertaisen veloituksen. Tämä mahdollistaa myös erien täsmäytyksen suorittamisen, jotta voimme varmistaa työmme offline-tilassa.
• Teemme asynkronisia (mutta silti lähes reaaliaikaisia) saldopäivityksiä synkronisten päivitysten sijaan, jotta voimme luoda seurantaketjun. Sallimme pienen viiveen käyttäjän saldon päivittymisessä, jotta voimme todistaa järjestelmän toimivuuden ja vakuuttaa käyttäjillemme, ettemme laskuta heitä virheellisesti. Kun lyhyt viive johtaa siihen, että ylitämme käyttäjän krediittisaldon, hyvitämme sen automaattisesti; valitsemme todennettavan oikeellisuuden ja käyttäjän luottamuksen tiukan valvonnan sijaan.
• Vähennämme krediittisaldoa ja lisäämme saldon päivitysmerkinnän yhteen atomitason tietokantatapahtumaan. Saldopäivitykset käsitellään tilikohtaisesti, joten samanaikaiset pyynnöt eivät voi koskaan kilpailla samojen hyvitysten käyttämisestä. Saldon päivitysmerkintä sisältää sekä veloitussumman että viittauksen takaisin siihen monetisointitapahtumaan, joka käynnisti päivityksen. Tämän paketointi yhteen tietokantatapahtuman takaa, että meillä on tarkka seurantaketju jokaisesta krediittisaldon muutoksesta.

Kaikki tämä perusteellisuus tukee yhtä tavoitetta: tehdä pääsystä yksinkertaista ja turvallista. Kun ihmiset luovat tai koodaavat, heidän ei pitäisi joutua miettimään, meneekö pyyntö läpi, veloitetaanko heiltä liikaa tai onko heidän saldonsa täsmällinen. Varmistamalla, että käyttö, laskutus ja saldot ovat todennettavasti oikein, tarjoamme käyttäjille järjestelmän, joka ei häiritse heidän käyttökokemustaan. Näin voimme korvata kovat pysähdykset jatkuvalla käytöllä—ja se tekee krediiteistä käyttökelpoisia todellisen työn keskellä, ei vain laskutuksessa.

Lähestymistapamme ohjaava periaate on käyttäjän etenemisen suojaaminen. Kukin arkkitehtuuripäätös heijastuu käyttäjäkohtaiseen lopputulokseen: reaaliaikaiset saldot estävät tarpeettomat keskeytykset, atominen kulutus estää tuplaveloituksen, ja yhtenäinen käyttöoikeuslogiikka varmistaa ennustettavan toiminnan. Tuloksena on, että ihmiset voivat työskennellä pidempään, tutkia syvällisemmin ja viedä projekteja pidemmälle ilman, että he kohtaavat tiukkoja rajoituksia tai joutuvat muuttamaan suunnitelmia ennenaikaisesti.

Kun käyttäjät ovat sitoutuneita, järjestelmän tulisi auttaa heitä jatkamaan, ei estää heitä. Rajat ja krediitit katoavat taustalle.

Tämän kokemuksen luominen vaati käyttöoikeuksien, käytön ja laskutuksen tarkastelua yhtenä kokonaisuutena sekä sellaisen infrastruktuurin rakentamista, jossa oikeellisuus on ensisijainen tuoteominaisuus. Sama perusta voi ajan myötä laajentua useampiin tuotteisiin; Codex ja Sora ovat vasta alkua.