Отвъд лимитите: разширяване на достъпа до Codex и Sora

През изминалата година както Codex, така и Sora бяха бързо възприети, като използването им бързо надхвърли първоначалните ни очаквания. Забелязахме последователен модел: потребителите се потапят в продукта, намират реална стойност и след това се сблъскват с ограниченията на заявките.

Ограниченията на заявките могат да спомогнат за изглаждане на търсенето и да осигурят справедлив достъп, когато обаче потребителите извличат полза, достигането на твърдо ограничение може да бъде разочароващо. Искахме да намерим начин потребителите да продължат използването, като същевременно защитим производителността на системата и доверието на потребителите в нашия подход.

За да разрешим този проблем, създадохме механизъм за достъп в реално време, който отчита използването. Един от слоевете в този механизъм е възможността за закупуване на кредити. Когато потребителите надхвърлят лимитите си за заявки, кредитите им позволяват да продължат да използват нашите продукти, като изразходват наличния си кредитен баланс.

Под тази система се крие сложен механизъм, който съчетава лимити, проследяване на използването в реално време и кредитни баланси в единен модел за достъп. Тази публикация обяснява защо мащабирането на Codex и Sora наложи преосмисляне на контрола на достъпа, как доказуемо коректна система в реално време съчетава ограничения на заявките и кредити на заявка и как тази основа вече осигурява допълнителен достъп и до двата продукта.

Ако погледнем от по-широка перспектива, традиционните модели за достъп обикновено налагат избор:

• Ограниченията на заявките могат да бъдат полезни в началото, но оставят потребителите с лошо впечатление, когато се изчерпат: „върнете се по-късно“
• Таксуването според използването е гъвкаво, но кара потребителите да плащат още от първия токен — не е идеално за подпомагане на ранно проучване

За Codex и Sora нито един от тях не беше достатъчен сам по себе си. Ако просто повишим ограниченията на заявките, ще изгубим важните механизми за изглаждане на търсенето и контрол на справедливостта и ще изчерпим капацитета си да обслужваме всички. Ако разчитахме изцяло на асинхронно таксуване според използването, щяхме да въведем забавяне, надвишаване на лимитите или проблеми при съгласуването — точно от онези проблеми, които потребителите забелязват, когато са най-ангажирани.

Това, от което се нуждаехме, беше единна хибридна система, която съчетава ограничения в реално време с достъп на принципа „плащаш, колкото използваш“:

Тази система трябваше да:

• Прилагайте ограничения на заявките, докато не бъдат достигнати
• Безпроблемно преминете към кредити в рамките на същата заявка
• Взема това решение в реално време
• Да бъде изключително точна и да осигури възможност за отчитане при проследяване на потреблението на кредити

Една от ключовите концептуални промени, които направихме, беше да моделираме достъпа като поток от решения. Вместо да питате „позволено ли е това?“, питаме „колко е позволено и откъде?“ Когато се отчита използването, системата следва следната последователност:

Този модел отразява как потребителите всъщност възприемат продукта. Ограниченията на заявките, безплатните нива, кредитите, промоциите и корпоративните права са само слоеве в един и същ пакет от решения. От гледна точка на потребителя, те не „превключват системи“ — те просто продължават да използват Codex и Sora. Затова кредитите изглеждат невидими: те са просто още един елемент в потока.

Оценихме платформи на трети страни за таксуване и измерване на използването, за да управляваме потреблението на кредити. Те са особено подходящи за фактуриране и отчитане, но не отговаряха на две критични изисквания:

Когато потребител достигне лимит и има налични кредити, системата трябва да бъде информирана незабавно. Отчитането с най‑добри усилия или със закъснение води до изненадващи блокирания, непоследователни баланси и неправилни разходи. За интерактивни продукти като Codex и Sora, тези неуспехи стават видими и разочароващи.

Също така трябваше да осигурим прозрачност за всеки резултат:

• Защо дадена заявка е била разрешена или блокирана
• Колко използване се изразходва
• Какви лимити или баланси са били приложени

Тази функционалност трябваше да бъде тясно интегрирана в нашия процес на вземане на решения, вместо да бъде решавана изолирано в отделна платформа за таксуване, която виждаше само част от случващото се. За да осигурим на потребителите достъп до нашите продукти, без да нарушаваме доверието, трябваше да имаме пълен контрол върху точността, времевите рамки и възможността за наблюдение. Това ни насочи към вътрешно решение.

За да осигурим това, създадохме разпределена система за управление на използването и баланса, проектирана специално за синхронни решения за достъп.

На високо ниво системата:

• Проследява използването на функции от всеки потребител
• Поддържа прозорци за ограничаване на заявите
• Поддържа кредитни баланси в реално време
• Дебитира баланси идемпотентно чрез поточен асинхронен процесор

Всяка заявка преминава през един-единствен път за оценка, който взема решение в реално време за това колко използване е разрешено, като синхронно консумира от ограниченията на заявките и, ако е необходимо, проверява наличието на достатъчно кредити, след това връща един окончателен резултат, като урежда всички дебитирания на кредити асинхронно. Това гарантира последователно поведение на всички продукти и елиминира дублиращата се логика в различните екипи.

Един от основните принципи на проектиране на тази система е, че трябва да можем да докажем, че нашето фактуриране е правилно. Това отразява корените на нашата кредитна поддръжка, която произхожда от корпоративните клиенти. В горната системна диаграма имаме три отделни набора от данни, които са свързани помежду си:

• Събития при използване на продукта: Какво всъщност е направил потребителят
• Събития за монетизация: Какво таксуваме на потребителя за неговото използване
• Актуализации на баланса: Колко сме коригирали кредитния баланс на потребителя и защо

Тези набори от данни не са случаен страничен продукт. Те всъщност задвижват системата, като всеки набор задейства следващия. Разделянето на случилото се, на свързаните с него разходи и на дебитираните суми ни позволява да извършваме независим отчет, възпроизвеждане и съгласуване на всеки слой. Това е умишлен компромис, при който даваме приоритет на доказуемата коректност, за сметка на леко забавяне на актуализациите на кредитния баланс. Как го постигнахме:

• Събитията за използване на продукта се публикуват за всяка потребителска активност, независимо дали тя води до потребление на кредити или не. Това осигурява проследимост на активността на потребителите и ни позволява да обясним защо начислихме или не начислихме кредити.
• Всяко събитие има стабилен идемпотентен ключ, така че повторните опити, повторните изпълнения или рестартирането от работниците никога не могат да доведат до двойно дебитиране на баланса, което предотвратява двойното таксуване. Това също така ни позволява да извършим пакетно съгласуване, за да проверим работата си офлайн.
• Извършваме асинхронни (но все пак почти в реално време) актуализации на баланса вместо синхронни актуализации, за да създадем следа за отчитане. Допускаме малко забавяне при актуализирането на баланса на потребителя, за да докажем, че системата функционира и да уверим потребителите, че не ги таксуваме неправилно. Когато това кратко забавяне доведе до превишаване на кредитния баланс на даден потребител, ние автоматично го възстановяваме. Избираме доказуемата коректност и доверието на потребителя пред стриктното прилагане.
• Намаляваме Кредитния баланс и вмъкваме запис за Актуализация на баланса в рамките на една атомарна трансакция в базата данни. Актуализациите на баланса са сериализирани за всеки акаунт, така че едновременните заявки никога не могат да се състезават да изразходват едни и същи кредити. Записът Актуализация на баланса съдържа както дебитната сума, така и връзка към събитието за монетизация, което е предизвикало актуализацията. Обвиването на това в една-единствена трансакция в базата данни гарантира, че имаме следа за отчетност за всяка корекция на кредитния баланс.

Цялата тази строгост има една цел: да направи достъпа лесен и безопасен. Когато хората създават или пишат код, не би трябвало да се чудят дали заявката ще бъде изпълнена, дали ще им бъде начислена прекомерна сума или дали балансът им е точен. Като гарантираме, че използването, фактурирането и балансите са доказуемо коректни, ние предоставяме на потребителите система, която не отвлича вниманието от тяхното изживяване. Това ни позволява да заменим твърдите прекъсвания с непрекъснат достъп и прави кредитите използваеми по време на реална работа, а не само във фактура.

Водещият принцип на нашия подход е да запазим инерцията на потребителите. Всяко архитектурно решение води до резултат, видим за потребителя: балансите в реално време предотвратяват ненужни прекъсвания, атомарното потребление предотвратява двойно таксуване, а унифицираната логика за достъп осигурява предсказуемо поведение. Резултатът е, че хората могат да работят по-дълго, да изследват по-задълбочено и да развиват проектите по-нататък, без да се сблъскват с твърди ограничения или преждевременни промени в плана.

Когато потребителите са ангажирани, системата трябва да им помага да продължат, а не да им пречи. Ограниченията и кредитите остават на заден план.

Изграждането на това преживяване изискваше преосмисляне на достъпа, използването и таксуването като единна система и изграждане на инфраструктура, която третира коректността като основна продуктова характеристика. Същата основа може да се разшири до повече продукти с течение на времето, Codex и Sora са само началото.