Nad rámec limitů požadavků: škálování přístupu do Codex a Sora

V uplynulém roce zaznamenaly Codex i Sora rychlé zavádění a jejich používání rychle překročilo naše původní očekávání. Všimli jsme si opakující se situace: uživatelé začnou, najdou skutečnou hodnotu a pak narazí na limity počtu požadavků.

Limity počtu požadavků mohou pomoci vyrovnávat poptávku a zajišťovat spravedlivý přístup, když ale uživatelé dostávají hodnotu, může náraz na limity frustrující. Chtěli jsme najít způsob, jakým by uživatelé mohli pokračovat a zároveň chránit výkon systému a důvěru uživatelů v náš přístup.

Abychom tento problém vyřešili, vytvořili jsme systém pro přístup v reálném čase, který počítá využití. Jednou z vrstev tohoto modulu je možnost zakoupit kredity. Když uživatelé překročí své limity, kredity jim umožní pokračovat v používání našich produktů utrácením zůstatku kreditu.

Pod tím se skrývá komplexní systém, který v jednom modelu přístupu slučuje limity, sledování využití v reálném čase a zůstatky kreditů. Tento příspěvek se zabývá tím, proč škálování Codex a Sora vyžadovalo přehodnocení řízení přístupu, jak prokazatelně správný systém fungující v reálném čase kombinuje limity počtu požadavků a kredity na požadavek a jak tento základ nyní vede k rozšířenému přístupu pro oba produkty.

Když se na to podíváme z nadhledu, tradiční modely přístupu mají tendenci nutit k volbě:

• Limity počtu požadavků mohou být zpočátku užitečné, ale uživatelé jsou nespokojeni, když jim dojdou: „vraťte se později“
• Účtování podle využití je flexibilní, ale uživatelé platí od prvního tokenu, což není ideální pro podporu počátečního prozkoumávání

Pro Codex a Sora ani jedno samo o sobě nestačilo. Pokud bychom prostě zvýšili limity sazeb, ztratili bychom důležité mechanismy pro vyrovnávání poptávky a zajištění spravedlnosti a vyčerpali bychom kapacitu pro všechny. Pokud bychom se spoléhali výhradně na asynchronní fakturaci za využití, docházelo by k problémům se zpožděním, překročením limitu nebo odsouhlasením – přesně k těm problémům, kterých si uživatelé všímají, když mají největší zájem.

Místo toho jsme potřebovali jeden hybridní systém kombinující limity v reálném čase s přístupem průběžných plateb:

Tento systém musel:

• Vynucování limitů požadavků, dokud jich není dosaženo
• Plynulý přechod na kredity v rámci stejného požadavku
• Rozhodovat v reálném čase
• Být důsledně přesný a zajistit auditovatelnost při sledování spotřeby kreditů

Jedním z klíčových koncepčních posunů, které jsme provedli, bylo modelování přístupu jako rozhodovacího vodopádu. Místo otázky „je to povolené?“ se ptáme „kolik je povoleno a odkud?“. Při počítání spotřeby systém prochází následující sekvencí:

Tento model odráží, jak uživatelé produkt skutečně vnímají. Limity počtu požadavků, bezplatné úrovně, kredity, propagační akce a podniková oprávnění jsou jen vrstvy ve stejném rozhodovací množině. Uživatel ze svého pohledu „nepřepíná systém“ – prostě nadále používá Codex a Sora. Proto kredity působí neviditelně: jsou jen dalším prvkem ve vodopádu.

Vyhodnotili jsme platformy třetích stran pro fakturaci a měření spotřeby k práci se spotřebou kreditů. Jsou vhodné pro fakturaci a vykazování, ale nesplňují dva zásadní požadavky:

Když uživatel dosáhne limitu a má k dispozici kredity, systém to musí zjistit okamžitě. Počítání s maximálním úsilím nebo zpožděné počítání se projevuje jako překvapivé bloky, nekonzistentní zůstatky a nesprávné poplatky. U interaktivních produktů, jako jsou Codex a Sora, jsou tyto nedostatky viditelné a frustrující.

Také jsme potřebovali nabídnout transparentnost v případě každého výsledku:

• Proč byl požadavek povolen nebo zablokován
• Kolik využití bylo spotřebováno
• Jaká omezení nebo zůstatky byly použity

Tuto funkci bylo nutné pevně integrovat do našeho rozhodovacího vodopádu, a ne řešit ji izolovaně na samostatné platformě pro fakturaci spotřeby, která by sledovala pouze jednu část toho, co se děje. Abychom uživatelům umožnili přístup ke svým produktům bez kompromisů v oblasti důvěry, potřebovali jsme plnou kontrolu nad správností, načasováním a sledovatelností. To nás přivedlo k internímu řešení.

K tomu jsme vytvořili distribuovaný systém využití a vyvažování, který byl navržen speciálně pro synchronní rozhodování o přístupu.

Na vysoké úrovni systém:

• Sleduje využití na uživatele a na funkci
• Udržuje okna limitů požadavků
• Udržuje kreditní zůstatky v reálném čase
• Idempotentně odepisuje zůstatky pomocí streamovacího asynchronního nástroje na zpracování

Každý požadavek prochází jedinou vyhodnocovací cestou, která v reálném čase rozhoduje o povoleném množství využití synchronním spotřebováním z limitů počtu požadavků a v případě potřeby ověřováním dostatečného počtu kreditů. Poté vrací jeden definitivní výsledek a asynchronně vyrovnává veškeré debetní účty. To zajišťuje konzistentní chování napříč produkty a eliminuje duplicitní logiku napříč týmy.

Jedním z klíčových principů návrhu tohoto systému je, že musíme být schopni prokázat, že naše fakturace je správná. To odráží původ naší podpory kreditů u firemních zákazníků. Ve výše uvedeném systémovém diagramu máme tři samostatné datové sady, které jsou všechny propojeny:

• Události využívání produktu: Co uživatel skutečně udělal
• Události monetizace: Co účtujeme uživateli za jeho používání
• Aktualizace zůstatku: O kolik jsme upravili zůstatek kreditů uživatele a proč

Tyto datové sady nejsou jen vedlejším produktem, ve skutečnosti na nich systém stojí, přičemž každá další datová sada spouští tu další. Oddělení toho, co se stalo, všech souvisejících poplatků a toho, co jsme strhli z účtu, nám umožňuje nezávisle auditovat, přehrávat a odsouhlasovat každou vrstvu. Jedná se o záměrný kompromis, kdy upřednostňujeme prokazatelnou správnost, a to za cenu mírného zpoždění aktualizací zůstatku kreditu. Jak jsme toho dosáhli:

• Události používání produktů se zveřejňují pro veškerou aktivitu uživatelů, ať už vede ke spotřebě kreditů, či nikoli. To poskytuje auditní stopu pro aktivitu uživatelů a umožňuje nám vysvětlit, proč jsme kredity účtovali, nebo neúčtovali.
• Každá událost nese stabilní idempotentní klíč, takže opakované pokusy, přehrání nebo restartování nástrojů nikdy nevedou ke dvojnásobnému vyrovnání zůstatku, což zabraňuje dvojímu účtování. To nám také umožňuje spustit dávkové odsouhlasení a ověřovat svou práci offline.
• Provádíme asynchronní (ale stále téměř v reálném čase) aktualizace zůstatku místo synchronních aktualizací, abychom vytvořili auditní stopu. Tolerujeme malé zpoždění v aktualizaci zůstatku uživatele, abychom mohli prokázat funkčnost systému a ujistit naše uživatele, že jim neúčtujeme chybně. Když toto krátké zpoždění způsobí překročení zůstatku kreditu uživatele, automaticky ho vrátíme, upřednostňujeme prokazatelnou správnost a důvěru uživatelů před přísným vymáháním.
• Snížíme zůstatek kreditu a vložíme záznam o aktualizaci zůstatku do jedné atomické databázové transakce. Aktualizace zůstatku jsou serializovány pro každý účet, takže souběžné požadavky se nikdy nemohou předhánět v utracení stejných kreditů. Záznam o aktualizaci zůstatku obsahuje jak ztrženou částku, tak i přiřazení k události monetizace, která aktualizaci spustila. Zahrnutí těchto údajů do jedné databázové transakce nám zaručuje auditní záznam pro každou úpravu zůstatku kreditu.

Veškerá tato důslednost má jeden cíl: zjednodušit a zajistit bezpečnost přístupu. Když lidé tvoří nebo programují, neměli by se muset trápit tím, zda požadavek projde, zda jim bude účtována vyšší částka nebo zda je jejich zůstatek přesný. Tím, že prokazatelně zajišťujeme správné údaje o využití, fakturaci a zůstatcích, poskytujeme uživatelům systém, který jim nijak nenarušuje práci. Díky tomu můžeme nahradit pevné limity nepřetržitým přístupem – a díky tomu jsou kredity použitelné i uprostřed skutečné práce, ne jen na faktuře.

Hlavním principem našeho přístupu je ochrana dynamiky uživatelů. Každé architektonické rozhodnutí se odvíjí od výsledku zaměřeného na uživatele: zůstatky v reálném čase zabraňují zbytečným přerušením, atomická spotřeba zabraňuje dvojímu účtování a sjednocená přístupová logika zajišťuje předvídatelné chování. Výsledkem je, že lidé mohou pracovat déle, rozvíjet projekty do větší hloubky, aniž by museli čelit tvrdým limitům nebo předčasným změnám plánů.

Když jsou uživatelé aktivní, systém by jim měl pomáhat pokračovat, ne jim překážet. Limity a kredity mizí v pozadí.

Vytvoření takové funkčnosti vyžadovalo přehodnocení přístupu, používání a fakturace do jednoho systému a vybudování infrastruktury, která bere správnost jako klíčovou vlastnost produktu. Stejný základ se může časem rozšířit na další produkty, Codex a Sora jsou jen začátek.