Jak OpenAI obsługuje 800 milionów użytkowników ChatGPT

ChatGPT">ChatGPT ma 800 milionów użytkowników. Każdy wysyła pytania, dostaje odpowiedzi, synchronizuje historię między telefonem a laptopem. Miliony operacji na sekundę. A u podstaw? PostgreSQL — baza danych z lat 80.

To przypomina paradoks, prawda?

OpenAI właśnie pokazało, jak technologię sprzed czterech dekad można wyskalować do obsługi jednego z największych serwisów AI na świecie. I nie, to nie magia.

Gdy baza danych staje się wąskim gardłem

PostgreSQL zarządza danymi. Prosty opis: to miejsce, gdzie ChatGPT trzyma Twoje rozmowy, ustawienia, historię subskrypcji. Każde kliknięcie w aplikacji to zapytanie do bazy.

Jeden użytkownik? Zero problemu.

Milion jednocześnie? Baza zaczyna się dusić.

OpenAI stanęło przed wyborem: albo przepisać całą infrastrukturę od zera (co zajęłoby lata), albo nauczyć się skalować PostgreSQL w sposób, którego nikt wcześniej nie próbował w takiej skali. Wybrali to drugie.

Repliki — kopiuj dane, dziel obciążenie

bibliotekę z jednym egzemplarzem bestsellera. Kolejka za róg. Co robisz? Kupujesz 50 kopii i rozkładasz po całym budynku.

Repliki działają podobnie. Zamiast jednej bazy danych — dziesiątki jej kopii. Każda obsługuje kawałek ruchu. Użytkownik z Europy łączy się z repliką w Amsterdamie. Ktoś z Azji — z Singapuru.

Efekt? Zamiast jednego przytłoczonego serwera masz armię maszyn, każda ciągnie ułamek zapytań.

Haczyk: repliki muszą być zsynchronizowane. Zmieniasz hasło na telefonie? Replika w Amsterdamie musi o tym wiedzieć natychmiast. Inaczej logowanie na laptopie się nie uda.

Cache — nie pytaj dwa razy o to samo

Większość zapytań to powtórki. Otwierasz ChatGPT — system sprawdza subskrypcję. Pięć minut później znowu otwierasz. To samo pytanie.

Cache (kesz) to pamięć podręczna. Zamiast za każdym razem pytać bazę, system zapamiętuje odpowiedź. Kolejne zapytanie? Obsługiwane z pamięci, bez dotykania bazy.

Analogia: zamiast za każdym razem dzwonić do banku z pytaniem o stan konta, zapisujesz sobie kwotę na kartce. Dopóki nie wydasz pieniędzy, kartka jest aktualna.

OpenAI cachuje dane, które rzadko się zmieniają — ustawienia konta, preferencje językowe, info o subskrypcji. Wynik? 70% zapytań obsługiwanych bez dotykania bazy.

Rate limiting — jeden użytkownik nie zablokuje systemu

Ktoś pisze skrypt, który wysyła 10 tysięcy zapytań na sekundę. Bot, błąd w kodzie — nieważne. Efekt? Baza tonie w żądaniach jednego użytkownika. 799 milionów pozostałych czeka.

Rate limiting to ogranicznik. System mówi: "Możesz wysłać max 100 zapytań na minutę. Przekroczysz? Poczekasz".

Jak ochroniarz w klubie — wpuszcza partiami, żeby w środku nie zrobiło się za ciasno.

OpenAI stosuje rate limiting na kilku poziomach: per użytkownik, per aplikacja, per region. Jeden serwer generuje anomalnie dużo ruchu? System automatycznie go spowalnia.

Workload isolation — nie mieszaj gorącego z zimnym

Nie wszystkie zapytania są równe. Niektóre krytyczne: uwierzytelnienie, rozpoczęcie rozmowy. Inne mogą poczekać: synchronizacja historii, aktualizacja statystyk.

Workload isolation rozdziela zadania. Krytyczne operacje trafiają do dedykowanych serwerów. Mniej pilne — do osobnej puli, która nie blokuje głównego ruchu.

W szpitalu ostry dyżur ma osobny wjazd. Karetka nie stoi w kolejce za kimś, kto przyszedł po receptę.

OpenAI wydzieliło kilka kategorii:

• Tier 1 (krytyczne): logowanie, rozpoczęcie konwersacji, płatności
• Tier 2 (ważne): odczyt historii, zmiana ustawień
• Tier 3 (tło): analityka, logi, synchronizacja międzyregionalna

Każdy tier ma własne serwery. Tier 3 się zapcha? Nie odczujesz tego — nadal się zalogujesz i wyślesz wiadomość.

Monitoring — widzieć problem przed użytkownikiem

System monitoringu to tablica rozdzielcza w samolocie. Setki wskaźników w czasie rzeczywistym: ile zapytań na sekundę, jaki czas odpowiedzi, ile replik działa sprawnie.

OpenAI używa narzędzi, które alarmują, gdy:

• Czas odpowiedzi przekracza 200 milisekund
• Replika opóźnia się w synchronizacji
• Cache przestaje działać efektywnie
• Ruch z jednego regionu gwałtownie rośnie

Większość problemów rozwiązuje się automatycznie. System wykrywa przeciążoną replikę? Przekierowuje ruch gdzie indziej. Cache się zapełnia? Czyści najstarsze wpisy.

Inżynierowie wchodzą tylko wtedy, gdy automatyka nie radzi sobie sama.

Czemu PostgreSQL, a nie coś nowszego?

Pytanie nasuwa się samo: czemu nie użyć czegoś świeższego? Baz zaprojektowanych od podstaw pod miliony użytkowników?

Odpowiedź: PostgreSQL ma 35 lat historii. Co to oznacza.

• Stabilność przetestowaną przez tysiące firm
• Ogromną społeczność, która rozwiązała już większość problemów
• Narzędzia do debugowania, optymalizacji, backupu wypracowane przez dekady
• Kompatybilność z niemal każdym językiem programowania

Nowe bazy obiecują cuda. W praktyce? Często brakuje im dojrzałości. Napotkasz błąd — czekasz na łatkę od producenta. W PostgreSQL ktoś już to naprawił 10 lat temu.

OpenAI postawiło na przewidywalność.

I wyszło.

Co to oznacza dla Ciebie?

Nie budujesz ChatGPT. Ale zasady, które zastosowało OpenAI, działają w każdej skali.

Masz aplikację z rosnącą liczbą użytkowników? Zamiast przepisywać wszystko od zera, spójrz na to, co już masz. Może wystarczy dodać repliki, poprawić cachowanie, oddzielić krytyczne zadania od mniej pilnych.

Czasem skalowanie to nie rewolucja.

To seria małych, przemyślanych optymalizacji.

OpenAI pokazało, że nawet technologia sprzed dekad może obsłużyć 800 milionów użytkowników. Wystarczy wiedzieć, jak jej użyć.

Źródła

• OpenAI Blog – Scaling PostgreSQL to power 800 million ChatGPT users