Poza limitami zapytań: skalowanie dostępu do Codex i Sora

W ubiegłym roku zarówno Codex, jak i Sora zyskały na popularności, a ich użycie szybko przekroczyło nasze pierwotne oczekiwania. Zaobserwowaliśmy stały wzorzec: użytkownicy zaczynają korzystać z serwisu, odkrywają jego prawdziwą wartość, a następnie napotykają ograniczenia dotyczące limitów zapytań.

Limity zapytań mogą ułatwić regulowanie popytu i zapewnić sprawiedliwy dostęp, jednak osiągnięcie limitu może być frustrujące, gdy użytkownicy czerpią korzyści z systemu. Chcieliśmy znaleźć sposób, aby użytkownicy mogli kontynuować pracę, zachowując przy tym wydajność systemu i zaufanie użytkowników do naszej metody działania.

Aby rozwiązać ten problem, stworzyliśmy silnik dostępu w czasie rzeczywistym, który zlicza wykorzystanie. Jedną z warstw tego silnika jest możliwość zakupu kredytów. Gdy użytkownicy przekroczą limity zapytań, kredyty pozwalają im nadal korzystać z naszych produktów, wykorzystując saldo kredytów.

Pod spodem znajduje się złożony system, w którym połączyliśmy limity, śledzenie wykorzystania w czasie rzeczywistym i salda kredytów w jednym modelu dostępu. W tym artykule wyjaśniamy, dlaczego skalowanie Codex i Sora wymagało ponownego przeanalizowania kontroli dostępu, w jaki sposób działający w czasie rzeczywistym system o udowodnionej poprawności łączy limity zapytań i kredyty na żądanie, a także jak te fundamenty otwierają obecnie dodatkowe możliwości dostępu do obu produktów.

Patrząc z szerszej perspektywy, tradycyjne modele dostępu zazwyczaj zmuszają do dokonania wyboru:

• Limity zapytań mogą być przydatne na początku, ale po ich wyczerpaniu użytkownicy odczuwają frustrację: „wróć później”
• Rozliczenia oparte na zużyciu są elastyczne, ale użytkownicy płacą od pierwszego tokena, co nie jest idealnym rozwiązaniem w przypadku wczesnej eksploracji

W przypadku Codex i Sora żadne z nich nie było wystarczające samo w sobie. Gdybyśmy po prostu podnieśli limity zapytań, stracilibyśmy ważne mechanizmy wyrównywania popytu i kontroli sprawiedliwości oraz wyczerpaliśmy możliwości obsługi wszystkich użytkowników. Gdybyśmy opierali się wyłącznie na asynchronicznym rozliczaniu zużycia, wprowadzilibyśmy opóźnienia, nadwyżki lub problemy z uzgodnieniem rozliczeń – czyli dokładnie te problemy, które użytkownicy dostrzegają, gdy są najbardziej zaangażowani.

Potrzebowaliśmy natomiast jednego systemu hybrydowego, łączącego limity w czasie rzeczywistym z dostępem opartym na modelu płatności za użycie:

System miał spełniać następujące wymagania:

• Stosowanie limitów zapytań do momentu ich osiągnięcia
• Płynne przejście do kredytów w ramach tego samego zapytania
• Podejmowanie tej decyzji w czasie rzeczywistym
• Rygorystyczna dokładność i możliwość kontroli podczas śledzenia zużycia kredytu

Jedną z kluczowych zmian koncepcyjnych, jakie wprowadziliśmy, było modelowanie dostępu jako kaskady decyzji. Zamiast pytać „czy to jest dozwolone?”, pytamy: „jak wiele można zrobić i od którego miejsca?”. Podczas liczenia zużycia system wykonuje następującą sekwencję:

Model ten odzwierciedla rzeczywiste doświadczenia użytkowników związane z produktem. Limity zapytań, bezpłatne poziomy, kredyty, promocje i uprawnienia dla przedsiębiorstw to tylko kolejne warstwy tego samego stosu decyzji. Z punktu widzenia użytkownika nie „zmienia się systemu” – po prostu nadal korzysta z Codex i Sora. Dlatego kredyty zdają się niewidoczne: są po prostu kolejnym elementem w wodospadzie.

Przeanalizowaliśmy platformy rozliczeniowe i pomiarowe innych firm pod kątem obsługi zużycia kredytów. Są one dobrze dostosowane do fakturowania i raportowania, ale nie spełniają dwóch kluczowych wymagań:

Gdy użytkownik osiągnie limit i ma dostępne kredyty, system musi o tym natychmiast wiedzieć. Liczenie z najlepszym wysiłkiem lub opóźnione pojawia się jako niespodziewane blokady, niespójne salda i nieprawidłowe obciążenia. W przypadku produktów interaktywnych, takich jak Codex i Sora, te problemy stają się widoczne i frustrujące.

Musieliśmy również zapewnić przejrzystość wszystkich wyników:

• Dlaczego żądanie zostało dopuszczone lub zablokowane
• Ile zużycia to pochłonęło
• Jakie ograniczenia lub salda zostały zastosowane

Ta funkcja musiała być ściśle zintegrowana z naszym procesem decyzyjnym, a nie rozwiązywana oddzielnie w ramach osobnej platformy rozliczeniowej, która pokazywała tylko fragment całości. Aby umożliwić użytkownikom dostęp do naszych produktów bez narażania zaufania, potrzebowaliśmy pełnej kontroli nad poprawnością, terminowością i obserwowalnością. To właśnie skłoniło nas do opracowania naszego własnego rozwiązania.

Aby to umożliwić, stworzyliśmy rozproszony system zarządzania wykorzystaniem i saldami, zaprojektowany specjalnie do synchronicznych decyzji dotyczących dostępu.

Na wysokim poziomie system:

• Śledzi wykorzystanie, na użytkownika i na funkcję
• Utrzymuje okna limitów zapytań
• Prowadzi salda kredytów w czasie rzeczywistym
• Salda obciążeń są przetwarzane w idempotentny sposób przez strumieniowy procesor asynchroniczny

Każde żądanie przechodzi przez jedną ścieżkę oceny, która w czasie rzeczywistym podejmuje decyzję o dopuszczalnym wykorzystaniu, synchronicznie wykorzystując limity zapytań i, w razie potrzeby, weryfikując dostępność odpowiedniej liczby kredytów. Następnie zwraca jeden ostateczny wynik, asynchronicznie obciążając saldo kredytów. Zapewnia to spójne działanie wszystkich produktów i eliminuje powielanie logiki w różnych zespołach.

Jedną z kluczowych zasad projektowania tego systemu jest to, że musimy być w stanie udowodnić, że nasze rozliczenia są prawidłowe. Odzwierciedla to podstawy naszego mechanizmu obsługi kredytów, którego początki wiążą się z klientami korporacyjnymi. Na powyższym schemacie systemu mamy trzy oddzielne zestawy danych, które są ze sobą powiązane:

• Zdarzenia związane z użyciem produktu: co faktycznie zrobił użytkownik
• Zdarzenia związane z monetyzacją: co pobieramy od użytkownika za korzystanie z usługi
• Aktualizacje salda: z ile zmniejszyliśmy saldo kredytów użytkownika i dlaczego

Te zbiory danych nie są przypadkowym produktem ubocznym; w rzeczywistości napędzają one system, a każdy zbiór danych uruchamia następny. Rozdzielenie tego, co się zdarzyło, wszelkich powiązanych obciążeń i tego, co naliczyliśmy, pozwala nam niezależnie kontrolować, odtwarzać i uzgadniać każdą warstwę. Jest to celowy kompromis, w którym priorytetowo traktujemy możliwą do zweryfikowania poprawność kosztem niewielkiego opóźnienia w aktualizacji salda kredytów. Jak to osiągnęliśmy:

• Wydarzenia związane z użyciem produktu są publikowane dla wszystkich działań użytkownika, niezależnie od tego, czy powodują one zużycie kredytów, czy nie. Zapewnia to ścieżkę audytu dla działań użytkownika i pozwala nam wyjaśnić, dlaczego obciążyliśmy saldo kredytów lub nie.
• Każde zdarzenie posiada stabilny klucz idempotencji, dzięki czemu ponowne próby, powtórki lub ponowne uruchomienia procesów roboczych nigdy nie mogą spowodować podwójnego obciążenia salda, co zapobiega podwójnemu naliczaniu opłat. Pozwala nam to również przeprowadzić zbiorcze uzgodnienie w celu weryfikacji naszej pracy w trybie offline.
• Aby stworzyć ścieżkę audytu, zamiast synchronicznych aktualizacji salda stosujemy aktualizacje asynchroniczne (ale nadal zbliżone do czasu rzeczywistego). Tolerujemy niewielkie opóźnienia w aktualizacji salda użytkownika, aby móc udowodnić, że system działa prawidłowo i zapewnić naszych użytkowników, że nie wystawiamy im błędnych rachunków. Gdy to krótkie opóźnienie powoduje przekroczenie salda kredytów użytkownika, automatycznie zwracamy nadwyżkę. Weryfikowalną poprawność i zaufanie użytkowników są dla nas ważniejsze niż ścisłe egzekwowanie zasad.
• Zmniejszamy saldo kredytów i wprowadzamy rekord aktualizacji salda w ramach jednej atomowej transakcji bazy danych. Aktualizacje salda są serializowane dla każdego konta, więc równoczesne żądania nigdy nie mogą rywalizować o wykorzystanie tych samych środków. Rekord aktualizacji salda zawiera zarówno wartość obciążenia, jak i przypisanie do zdarzenia dotyczącego monetyzacji, które spowodowało aktualizację; zawarcie tego w jednej transakcji bazy danych gwarantuje, że mamy ścieżkę audytu dla każdej modyfikacji salda kredytów.

Wszystkie te rygorystyczne środki służą jednemu celowi: zapewnieniu łatwego i bezpiecznego dostępu. Podczas tworzenia lub kodowania użytkownicy nie powinni zastanawiać się, czy żądanie zostanie zrealizowane, czy nie zostaną obciążeni zbyt wysokimi opłatami lub czy ich saldo jest prawidłowe. Dzięki zapewnieniu poprawności danych dotyczących użytkowania, rozliczeń i sald, oferujemy użytkownikom system, który nie rozprasza ich uwagi podczas korzystania z systemu. To właśnie pozwala nam zastąpić sztywne ograniczenia ciągłym dostępem – i sprawia, że kredyty można wykorzystać w trakcie rzeczywistej pracy, a nie tylko na fakturze.

Główną zasadą naszego podejścia jest dbanie o tempo pracy użytkowników. Każda decyzja dotycząca architektury ma wpływ na to, co widzi użytkownik: salda w czasie rzeczywistym zapobiegają niepotrzebnym przerwom, atomowe zużycie zapobiega podwójnemu obciążeniu, a ujednolicona logika dostępu zapewnia przewidywalne zachowanie. Dzięki temu użytkownicy mogą pracować dłużej, zgłębiać temat bardziej szczegółowo i rozwijać projekty bez konieczności przerywania pracy lub przedwczesnego zmieniania planu.

Gdy użytkownicy angażują się w swoje działania, system powinien pomagać im kontynuować, a nie przeszkadzać. Limity i kredyty schodzą na dalszy plan.

Budowanie tego doświadczenia wymagało ponownego przeanalizowania kwestii dostępu, użytkowania i rozliczeń jako jednego systemu, jak również stworzenia infrastruktury, która traktuje poprawność jako kluczową cechę produktu. Z czasem te same podstawy mogą zostać rozszerzone na więcej produktów – Codex i Sora to dopiero początek.