Už tarifų ribų. Prieigos prie „Codex“ ir „Sora“ plėtimas

Per pastaruosius metus tiek „Codex“, tiek „Sora“ buvo sparčiai pritaikomi, o jų naudojimas greitai viršijo mūsų pradinius lūkesčius. Pastebėjome dėsningumą: naudotojai įsitraukia, atranda tikrąją vertę, o tada susiduria su spartos ribojimais.

Spartos ribojimai padeda sušvelninti paklausą ir užtikrinti sąžiningą prieigą; tačiau naudotojams gaunant vertę paslaugos ribojimas gali trukdyti. Norėjome rasti būdą naudotojams tęsti darbą, kartu apsaugant sistemos našumą ir naudotojų pasitikėjimą mumis.

Norėdami tai išspręsti, sukūrėme realaus laiko prieigos variklį, kuris skaičiuoja naudojimą. Vienas iš to variklio sluoksnių – galimybė įsigyti kreditus. Kai naudotojai viršija savo dažnio limitus, leidžiant kreditus jie gali toliau naudotis mūsų produktais.

Po tuo slypi sudėtinga sistema, kuri apjungia limitus, naudojimo stebėjimą realiuoju laiku ir kreditų likutį į vieną prieigos modelį. Šiame įraše aptariama, kodėl „Codex“ ir „Sora“ masto didinimas pareikalavo iš naujo pergalvoti prieigos kontrolę, kaip įrodomai teisinga, realiuoju laiku veikianti sistema sujungia užklausų dažnio ribas ir kreditus, ir kaip šis pagrindas dabar atveria papildomą prieigą abiem produktams.

Žvelgiant plačiau, tradiciniai prieigos modeliai dažnai verčia pasirinkti:

• Spartos ribojimai iš pradžių gali būti naudingi, tačiau kai jie pasibaigia, naudotojams palieka blogą įspūdį: „grįžkite vėliau“
• Mokėjimas pagal naudojimą yra lankstus, tačiau naudotojai moka nuo pirmo žetono, o tai nėra idealu ankstyvam tyrinėjimui

„Codex“ ir „Sora“ atveju nė vienos iš jų neužteko. Jei tiesiog padidintume srauto ribas, prarastume svarbias paklausos išlyginimo ir sąžiningumo kontrolės priemones ir pritrūktume pajėgumų aptarnauti visus. Jei visiškai pasikliautume asinchroniniu naudojimo apmokestinimu, sukeltume vėlavimus, viršijimus arba suderinimo problemas – būtent tokias problemas naudotojai pastebi, kai jie labiausiai įsitraukę.

Vietoj to mums reikėjo vienos hibridinės sistemos, kuri sujungtų realaus laiko apribojimus su prieiga pagal mokėjimo pagal poreikį:

Ši sistema turėjo:

• Taikykite srauto ribojimus iki jų pasiekimo
• Sklandžiai pereikite prie kreditų toje pačioje užklausoje
• Priimti sprendimą realiuoju laiku
• Stebint kreditų naudojimą, būti itin tiksli ir užtikrinti auditavimą

Vienas iš pagrindinių konceptualių pokyčių, kuriuos įgyvendinome, buvo prieigos modeliavimas – sprendimų srautas. Užuot klausę „ar tai galima?“, klausiame „kiek galima ir iš kur?“ Kai skaičiuojamas naudojimas, sistema vykdo šią seką:

Šis modelis atspindi tikrąją naudotojų patirtį su produktu. Spartos ribojimai, nemokami lygiai, kreditai, akcijos ir įmonių teisės yra tik skirtingi sluoksniai toje pačioje sprendimų hierarchijoje. Iš naudotojo perspektyvos, jie nekeičia sistemų – jie tiesiog toliau naudoja „Codex“ ir „Sora“. Štai kodėl kreditai atrodo nematomi: jie yra tik dar vienas elementas bendrame sraute.

Įvertinome trečiųjų šalių atsiskaitymo ir matavimo platformas, skirtas kreditų sunaudojimui valdyti. Jie puikiai tinka sąskaitų faktūrų išrašymui ir ataskaitų teikimui, tačiau neatitinka dviejų svarbių reikalavimų:

Kai naudotojas pasiekia limitą ir turi kreditų, sistema turi žinoti nedelsiant. Geriausių pastangų arba uždelstas skaičiavimas gali sukelti netikėtą užblokavimą, nenuoseklius likučius ir neteisingus mokesčius. Interaktyviems produktams, tokiems kaip „Codex“ ir „Sora“, šie gedimai tampa akivaizdūs ir varginantys.

Taip pat turėjome užtikrinti skaidrumą kiekvieno rezultato atžvilgiu:

• Kodėl užklausa buvo patvirtinta arba užblokuota
• Kiek išteklių sunaudota
• Kokie apribojimai ar balansai buvo taikomi

Šią galimybę reikėjo glaudžiai integruoti į mūsų sprendimų srautą, o ne spręsti atskirai, atskiroje naudojimo apmokestinimo platformoje, kuri matė tik vieną dalį to, kas vyko. Kad naudotojai galėtų pasiekti mūsų produktus nepažeidžiant pasitikėjimo, mums reikėjo visiškos kontrolės užtikrinant teisingumą, laiko valdymą ir stebimumą. Tai paskatino mus pasirinkti vidinį sprendimą.

Tam užtikrinti sukūrėme paskirstytą naudojimo ir balanso sistemą, specialiai sukurtą sinchroniniams prieigos sprendimams.

Aukštu lygiu sistema:

• Stebi naudojimą kiekvienam naudotojui ir kiekvienai funkcijai
• Palaiko srauto ribojimo langus
• Palaiko realiuoju laiku kredito likučius
• Idempotentiškai nurašo likučius naudodama srautinį asinchroninį procesorių

Kiekviena užklausa pereina vieną vertinimo kelią, kuris realiuoju laiku priima sprendimą, kiek naudojimo leidžiama, sinchroniškai naudodamas srauto ribojimo limitą ir, jei reikia, patikrindamas, ar pakanka kreditų; tuomet grąžina vieną galutinį rezultatą, o kreditų nurašymus sutvarko asinchroniškai. Tai užtikrina nuoseklų veikimą visuose produktuose ir pašalina dubliuotą logiką komandose.

Vienas iš pagrindinių šios sistemos projektavimo principų – įrodymas, jog mūsų sąskaitų išrašymas yra teisingas. Tai atspindi mūsų kredito palaikymo ištakas, kilusias iš verslo klientų. Aukščiau pateiktoje sistemos schemoje turime tris atskirus duomenų rinkinius, kurie visi tarpusavyje susiję:

• Produkto naudojimo įvykiai: ką naudotojas iš tikrųjų atliko
• Monetizacijos įvykiai: už ką imame mokestį iš naudotojo už naudojimąsi
• Likučio atnaujinimai: kiek koregavome naudotojų kredito likučius ir kodėl

Šie duomenų rinkiniai nėra atsitiktinis šalutinis produktas; jie iš tikrųjų valdo sistemą, ir kiekvienas duomenų rinkinys suaktyvina kitą. Atskyrus tai, kas įvyko, susijusius mokesčius ir tai, ką nurašėme, galime nepriklausomai audituoti, atkurti ir suderinti kiekvieną sluoksnį. Tai sąmoningas kompromisas, kai teikiame pirmenybę įrodomam teisingumui, net jei dėl to kreditų likučio atnaujinimai šiek tiek vėluoja. Kaip mes tai pasiekėme:

• Produkto naudojimo įvykiai skelbiami visai naudotojų veiklai, nesvarbu, ar tai lemia kreditų sunaudojimą, ar ne. Tai suteikia naudotojų veiklos audito pėdsaką ir leidžia mums paaiškinti, kodėl panaudojome kreditus (ar to nepadarėme).
• Kiekvienas įvykis turi stabilų idempotentiškumo raktą, todėl pakartotiniai bandymai, paleidimai ar darbiniai procesai niekada nenurašo balanso du kartus, taip išvengiant dvigubo apmokestinimo. Tai taip pat leidžia mums atlikti paketinį suderinimą, kad neprisijungus patikrintume savo darbą.
• Vietoj sinchroninių atnaujinimų atliekame asinchroninius (bet vis tiek beveik realaus laiko) likučio atnaujinimus, kad sukurtume audito pėdsaką. Leidžiame nedidelį vėlavimą atnaujinant naudotojo balansą, kad galėtume įrodyti, jog sistema veikia, ir užtikrinti naudotojus, kad jų neteisingai neapmokestiname. Kai dėl šio trumpo vėlavimo viršijame naudotojo kredito balansą, automatiškai jį grąžiname; renkamės įrodomą teisingumą ir naudotojų pasitikėjimą, o ne griežtą taisyklių laikymąsi.
• Viena atomine duomenų bazės operacija sumažiname Kredito likutį ir įterpiame Likučio atnaujinimo įrašą. Likučio atnaujinimai yra pateikiami kiekvienai paskyrai, todėl vienu metu pateikiamos užklausos nekonkuruoja dėl tų pačių kreditų išleidimo. Likučio atnaujinimo įraše pateikiama debeto suma ir priskyrimas monetizavimo įvykiui, inicijavusiam atnaujinimą; įtraukus tai į vieną duomenų bazės operaciją, užtikrinama, kad turime audito seką kiekvienam kredito balanso koregavimui.

Visas šis kruopštumas skirtas vienam tikslui: padaryti prieigą paprastą ir saugią. Kai žmonės kuria ar programuoja, jie neturėtų svarstyti, ar užklausa bus įvykdyta, ar jie permokės, ar jų likutis yra tikslus. Užtikrindami, kad naudojimas, atsiskaitymas ir likutis būtų teisingas, suteikiame naudotojams patirties netrikdančią sistemą. Būtent taip galime pakeisti sustojimus nuolatine prieiga – kreditai yra naudingi realaus darbo metu, o ne tik sąskaitoje faktūroje.

Mūsų pagrindinis principas – apsaugoti naudotojo tęstinumą. Kiekvienas architektūrinis sprendimas siejamas su naudotojui matomu rezultatu: realaus laiko balansai padeda išvengti nereikalingų pertraukų, atominis suvartojimas apsaugo nuo dvigubo apmokestinimo, o vieninga prieigos logika užtikrina nuspėjamą elgseną. Rezultatas yra tas, kad žmonės gali dirbti ilgiau, giliau tyrinėti ir toliau plėtoti projektus, nesusidurdami su griežtais sustojimais ar ankstyvais plano pakeitimais.

Kai naudotojai įsitraukia, sistema turėtų padėti jiems toliau dirbti, o ne trukdyti. Ribojimai ir kreditai pasitraukia į antrą planą.

Šios patirties kūrimas reikalavo iš naujo apmąstyti prieigą, naudojimą ir atsiskaitymą kaip vieningą sistemą bei sukurti infrastruktūrą, kurioje tikslumas laikomas svarbiausia produkto funkcija. Tas pats pagrindas laikui bėgant gali būti pritaikytas daugiau produktų; „Codex“ ir „Sora“ – tai tik pradžia.