Mahupiiranguid ületades: Codexi ja Sora juurdepääsu laiendamine

Viimase aasta jooksul on nii Codexi kui ka Sora kasutamine suurenenud, kusjuures kasutus ületas kiiresti meie esialgseid ootusi. Oleme märganud järjepidevat mustrit: kasutajad alustavad, leiavad, et tegu on väärtusliku tööriistaga ja jäävad hätta mahupiirangutega.

Mahupiirangud võivad aidata nõudlust ühtlustada ja tagada õiglase juurdepääsu; kuid kui kasutajad saavad kasu, võib järsk piirangute otsa sattumine põhjustada ärritust. Soovisime leida viisi, kuidas kasutajad saaksid jätkata kasutamist, kaitstes samal ajal süsteemi jõudlust ja kasutajate usaldust meie käsitluse vastu.

Selle lahendamiseks ehitasime reaalajas juurdepääsumootori, mis hindab kasutusandmeid. Üks selle mootori kihtidest on võimalus osta krediidipunkte. Kui kasutajad ületavad oma kasutuslimiite, võimaldab krediit neil meie tooteid krediidijäägi eest edasi kasutada.

Selle taga on keeruline süsteem, mis ühendab piirangud, reaalajas kasutuse jälgimise ja krediidipunktid ühtseks juurdepääsumudeliks. Selles postituses käsitleme, miks Codexi ja Sora laiendamine nõudis juurdepääsukontrolli ümbermõtestamist, kuidas tõestatult korrektne reaalajasüsteem ühendab mahupiirangud ja krediidipunktid iga päringu kohta ning kuidas see annab nüüd mõlemale tootele täiendava juurdepääsu.

Suuremat pilti vaadates sunnivad traditsioonilised juurdepääsumudelid tavaliselt valikut tegema:

• Mahupiirangud võivad alguses abiks olla, kuid loovad otsa saamisel halva kasutajakogemuse: „tule hiljem tagasi“
• Kasutuspõhine arveldamine on paindlik, kuid sunnib kasutajad maksma alates esimesest tokenist – see pole ideaalne esmase tutvumise toetamiseks.

Codexi ja Sora jaoks ei olnud kumbki eraldi piisav. Kui me lihtsalt tõstaksime mahupiiranguid, kaotaksime olulised nõudluse silumise ja õigluse tagamise mehhanismid ning meil ei oleks enam võimekust kõiki teenindada. Kui toetuksime täielikult asünkroonsele kasutuspõhisele arveldusele, tekitaksime viivitusi, ülekulusid või ühilduvusprobleeme – täpselt selliseid probleeme, mida kasutajad märkavad siis, kui nad on kõige intensiivsemalt protsessi kaasatud.

Selle asemel vajasime ühtset hübriidsüsteemi, mis ühendaks reaalajas piirangud ja kasutuspõhise juurdepääsu.

See süsteem pidi tegema järgmist:

• Rakenda mahupiiranguid kuni nende täitumiseni
• Liigu sujuvalt krediile sama päringu raames
• Langetama selle otsuse reaalajas.
• Olema krediidikasutuse jälgimisel väga täpne ja auditeeritav.

Üks peamisi kontseptuaalseid nihkeid, mille me tegime, oli juurdepääsu modelleerimine otsuste kaskaadina. Selle asemel, et küsida „kas see on lubatud?”, me küsime „kui palju on lubatud ja kuidas?”. Kasutuse arvestamisel läbib süsteem järgmised sammud.

See mudel peegeldab seda, kuidas kasutajad toodet tegelikult kogevad. Mahupiirangud, tasuta tasemed, krediit, kampaaniad ja ettevõtte õigused on kõik lihtsalt kihid samas otsuste tegemise kogumis. Kasutaja vaatenurgast nad ei „vaheta süsteeme“ vaid lihtsalt jätkavad Codexi ja Sora kasutamist. Seetõttu tundub krediit nähtamatu: see on lihtsalt üks järjekordne element jadas.

Hindasime kolmandate poolte kasutuspõhise arveldamise ja mõõtmise platvorme krediiditarbimise haldamiseks. Need sobivad hästi arveldamiseks ja aruandluseks, kuid ei täitnud kahte kriitilist nõuet:

Kui kasutaja limiit täitub ja tal on krediidipunkte saadaval, peab süsteem sellest kohe teadma. Parim pingutus või viivitusega loendamine väljendub ootamatute piirangute, ebajärjekindlate saldode ja valetasudena. Interaktiivsete toodete puhul, nagu Codex ja Sora, muutuvad need vead nähtavaks ja tekitavad frustratsiooni.

Pidime pakkuma iga tulemuse läbipaistvust:

• miks päring lubati või blokeeriti
• kui palju mahtu see kasutas
• Rakendatud piirangud või tasakaalustusmeetodid

See võimekus tuli tihedalt integreerida meie otsustusprotsessiga, mitte lahendada eraldi kasutuse arveldusplatvormil, mis nägi vaid üht osa toimuvast. Selleks, et kasutajad saaksid meie toodetele ligi ilma usaldust kahjustamata, vajasime täielikku kontrolli korrektsuse, ajastuse ja jälgitavuse üle. See suunas meid ettevõttesisese lahenduse leidmise poole.

Selleks ehitasime hajutatud kasutuse ja tasakaalustamise süsteemi, mis on spetsiaalselt loodud sünkroonsete juurdepääsuotsuste tegemiseks.

Üldisel tasemel teeb süsteem järgmist:

• jälgib kasutaja- ja funktsioonipõhist kasutust
• säilitab mahupiirangute aknaid
• haldab reaalajas krediidisaldosid
• debiteerib saldosid idempotentselt voogedastus-asünkroonse protsessori abil

Iga päring läbib ühe hindamistee, mis teeb reaalajas otsuse selle kohta, kui palju kasutamist on lubatud, tarbides sünkroonselt kiiruspiiranguid ja vajadusel kontrollides piisava krediidi olemasolu; seejärel tagastatakse üks lõplik tulemas, arveldades krediidivõlgnevuse asünkroonselt. See tagab järjepideva käitumise kõikide toodete lõikes ja välistab loogika dubleerimise meeskondade vahel.

Selle süsteemi üks peamisi disainipõhimõtteid on, et me peame suutma tõestada, et meie arveldus on korrektne. See peegeldab meie krediiditoe juuri, mis algasid ettevõtjatest klientidega. Eespool esitatud süsteemiskeemis on kolm eraldi andmekogumit, mis on omavahel seotud.

• Toote kasutamise sündmused: mida kasutaja tegelikult tegi
• Tulundussündmused: mille eest me kasutajalt tema kasutuse eest tasu võtame
• Saldouuendused: kui palju me kasutaja krediidisaldot muutsime ja miks

Need andmekogumid ei ole juhuslikud kõrvalsaadused; need juhivad süsteemi, kus iga andmekogum aktiveerib järgmise. Toimunu, sellega seotud tasude ja meie debiteeritu eristamine võimaldab meil iga kihti iseseisvalt auditeerida, taasesitada ja kooskõlastada. See on teadlik kompromiss, kus me eelistame tõendatavat korrektsust selle hinnaga, et krediidisaldo uuendamine toimub väikese viivitusega. Kuidas me selle saavutasime.

• Toote kasutusajalugu avaldatakse kogu kasutajategevuse kohta, olenemata sellest, kas selleks tarbiti krediiti või mitte. See loob kasutajategevuse kohta auditeerimisjälje ja võimaldab meil selgitada, miks me krediiti võtsime või mitte.
• Igal sündmusel on stabiilne idempotentsusvõti, seega ei saa uuesti proovimised, taasesitused ega tööprotsessi taaskäivitused kunagi saldolt topeltkrediiti võtta, mis hoiab ära topeltarvelduse. See võimaldab meil ka käivitada partii tasakaalustuse, et oma tööd võrguühenduseta kontrollida.
• Auditeerimisjälje loomiseks teeme sünkroonsete uuenduste asemel asünkroonseid (kuid siiski peaaegu reaalajas) saldouuendusi. Talume väikest viivitust kasutaja saldo ajakohastamisel, et tõendada süsteemi toimimist ja kinnitada kasutajatele, et me ei esita valesid arveid. Kui see lühike viivitus põhjustab kasutaja krediidijäägi ületamise, tagastame selle automaatselt; seame tõendatava korrektsuse ja kasutajate usalduse rangest jõustamisest ettepoole.
• Vähendame krediidisaldot ja lisame saldo värskenduse kirje ühe väikese andmebaasitehingu käigus. Saldo uuendused esitatakse jadana iga konto kohta, seega ei saa samaaegsed taotlused kunagi konkureerida samade krediidipunktide kulutamise nimel. Balance Update kirje sisaldab nii deebetsummat kui ka viidet värskenduse aktiveerinud tulundussündmusele; selle koondamine üheks andmebaasitehinguks tagab, et meil on auditijälg iga krediidisaldo korrigeerimise kohta.

Kogu see rangus toetab ühte eesmärki: muuta ligipääs lihtsaks ja turvaliseks. Kui inimesed loovad või kirjutavad koodi, ei peaks nad muretsema, kas päring läheb läbi, kas neilt võetakse liiga palju tasu või kas nende saldo on täpne. Muutes kasutuse, arvelduse ja saldod tõendatavalt korrektseks, loome kasutajate jaoks süsteemi, mis ei sega nende kasutajakogemust. See võimaldab meil asendada järsud katkestused pideva juurdepääsuga – ja see teeb krediidi kasutatavaks reaalajas, mitte ainult arvereal.

Meie käsitluse juhtiv põhimõte on kasutajate impulsi säilitamine. Iga arhitektuuriline otsus on seotud kasutajale nähtava tulemusega: reaalajas tasakaalustamine hoiab ära tarbetud katkestused, tasakaalustatud tarbimine hoiab ära topeltmaksustamise ja ühtne juurdepääsuloogika tagab etteaimatava käitumise. Tulemuseks on see, et inimesed saavad töötada kauem, süveneda ja arendada projekte põhjalikumalt, ilma et nad peaksid silmitsi seisma järskude peatuste või enneaegsete plaanimuudatustega.

Kui kasutajad on kaasatud, peaks süsteem aitama neil jätkata, mitte neid takistama. Piirangud ja krediit jäävad tagaplaanile.

Selle kogemuse loomine nõudis juurdepääsu, kasutuse ja arvelduse ümbermõtestamist ühe süsteemina ning sellise taristu loomist, mis käsitleb korrektsust esmase tootefunktsioonina. Sama platvorm võib aja jooksul laieneda rohkematele toodetele; Codex ja Sora on alles algus.