Jak zaprojektować wydajną architekturę backendu gry multiplayer, która wytrzyma 800 tys. CCU

Wirusowy sukces na Steam lub urządzeniach mobilnych to marzenie każdego niezależnego dewelopera dokładnie do momentu, w którym 50 000 graczy jednocześnie uderzy w Twoje API logowania w 30-sekundowym oknie. W ciągu kilku minut główna instancja PostgreSQL zatrzymuje się na 100% użycia procesora, pule połączeń się nasycają, kolejki matchmaking zamrażają, a tysiące negatywnych recenzji zalewają stronę na Steam, zanim Twój zespół w ogóle zdąży się obudzić.

Kiedy Gaggle Studios wydawało Goose Goose Duck, stanęło przed wyzwaniem, które łamie większość studiów: skalowaniem od skromnej bazy graczy indie do ponad 800 000 szczytowych użytkowników jednocześnie (CCU). Obsługa ruchu w czasie rzeczywistym takiej skali wymaga fundamentalnej zmiany podejścia do architektury backendu gry multiplayer. Nie możesz po prostu „uruchomić większych instancji AWS”, gdy Twoje wzorce dostępu do danych i topologia sieci są fundamentalnie wadliwe.

W tym głębokim tech-analizie przeanalizujemy dokładne wzorce architektoniczne wymagane do przetrwania hiperwzrostu, rozmontujemy wąskie gardła bazy danych, które zabijają gry z kategorii live-ops, oraz przejdziemy przez gotową do produkcji implementację bufora stanu typu write-behind.

---

Główne wąskie gardła w backendach gier o hiper-skali

Gdy tytuł multiplayer nagle zyskuje gigantyczną popularność, infrastruktura serwerowa rzadko pada z powodu renderowania pakietów po stronie klienta czy niskopoziomowej logiki gry napisanej w C++. Awaria występuje prawie zawsze na styku pamięci trwałej, routingu sesji w czasie rzeczywistym i orkiestracji instancji.

+-----------------------------------------------------------------------+
|                    WIRUSOWY RUCH NA SERWERACH                         |
+-----------------------------------------------------------------------+
                                   |
                                   v
                      +-------------------------+
                      |   Edge API Gateway      |
                      +-------------------------+
                                   |
            +----------------------+----------------------+
            |                                             |
            v                                             v
+-----------------------+                     +-----------------------+
|  Szturm Autoryzacji   |                     | Kolejka Matchmaking   |
|  - 10k req/s          |                     | - Blokady DB          |
|  - Walidacja Tokenów  |                     | - Alokacja Pokoi      |
+-----------------------+                     +-----------------------+
            |                                             |
            +----------------------+----------------------+
                                   |
                                   v
                      +-------------------------+
                      | Awaria Głównej Bazy DB  |
                      | (Wyczerpanie Połączeń)  |
                      +-------------------------+

1. Szturm autoryzacji i uzgadniania połączeń (Handshake)

Gdy wirusowy streamer kliknie „Graj”, setki tysięcy widzów uruchamiają klienta jednocześnie. Każdy gracz inicjuje sekwencję uzgadniania połączenia:

• Walidację tokena OAuth względem usług Steam/Epic
• Pobieranie profilu gracza (ekwipunek, kosmetyki, MMR, listy znajomych)
• Inicjalizację sesji i generowanie tokena

Jeśli klient odpytuje bezpośrednio główną bazę danych o profile graczy podczas logowania, baza padnie w kilka sekund. Standardowa instancja RDS skonfigurowana na maksymalnie 500 połączeń zatka się, gdy 15 000 przychodzących połączeń TCP spróbuje wykonać zapytanie SELECT * FROM player_profiles WHERE player_id = $1.

2. Zakleszczenia monolicznego system matchmakingu

Wiele backendów gier niezależnych polega na transakcjach relacyjnych baz danych do zarządzania kolejkami meczy (np. ustawianie flagi status = 'IN_MATCH' w wierszu tabeli players). Przy ponad 50 000 CCU blokady na poziomie wierszy, rywalizacja o indeksy i wolna serializacja zamieniają bazę danych w ścianę nie do przebicia. Matchmaking musi działać w całości w pamięci RAM, używając struktur bezblokadowych (lock-free) lub jednowątkowych pętli zdarzeń.

3. Wyczerpanie zasobów alokacji serwerów

Uruchamianie ciężkich, monolicznych serwerów dedykowanych bez interfejsu graficznego (takich jak niezoptymalizowane binarki Unreal Engine czy Unity) dla gier, które nie wymagają wysokoczęstotliwościowych przewidywań fizyki, to droga pomyłka w chmurze. Jeśli każda instancja serwera wymaga 1,5 GB pamięci RAM i 1 pełnego rdzenia vCPU do obsługi pokoju dla 10 graczy, utrzymanie 800 000 CCU wymaga 80 000 vCPU i 120 terabajtów RAM-u. Przy standardowych stawkach chmurowych koszty operacyjne mogą z łatwością przekroczyć 150 000 USD miesięcznie.

---

Projekt architektoniczny: Oddzielenie stanu od symulacji

Aby zbudować architekturę backendu gry multiplayer, która pozostaje wydajna podczas gwałtownego wzrostu, musisz wymusić ścisłą granicę pomiędzy trzema niezależnymi warstwami:

1. Warstwy Edge & Signaling: Obsługuje stałe połączenia klientów (WebSockets/gRPC), tokeny uwierzytelniania, routing czatu i sygnały matchmakingu.
2. Warstwy stanu w pamięci (In-Memory State): Przechowuje wszystkie ulotne dane rozgrywki (listy pokoi, pozycje graczy w lobby, parametry meczu) w ultraszybkich sklepach pamięci (np. Redis Clusters lub siatki pamięci klucz-wartość).
3. Warstwy trwałości danych (Persistent Storage): Asynchroniczna baza relacyjna lub dokumentowa (PostgreSQL/MongoDB) zarezerwowana wyłącznie dla stałych zapisów stanu (zmiany waluty, historia meczów, zapisy postępów).

[ Aplikacja Klienta ] ---> ( Trwałe WebSockets / gRPC )
                                   |
                                   v
                   [ Węzeł Edge API Gateway ]
                                   |
            +----------------------+----------------------+
            |                                             |
            v                                             v
[ Ephemeralny Węzeł Match ]      [ Stan w Pamięci Redis ]
    (Logika / Stan Pokoju)      (Kolejki Sesji i Meczu)
            |                                             |
            +----------------------+----------------------+
                                   |
                                   v
               [ Asynchroniczny Worker Write-Behind ]
                                   |
                                   v
                 [ Relacyjna Baza Danych (PostgreSQL) ]

Dzięki rozdzieleniu tych warstw napływ 100 000 nowych połączeń wpływa tylko na lekką warstwę Edge Signaling, która może skalować się hipotetycznie na tanich węzłach kontenerowych bez dotykania głównej bazy danych.

Jeśli rezygnujesz z wysokokosztowego odpytywania przez klienta (polling) na rzecz lekkiej komunikacji brzegowej, zapoznaj się z naszą analizą techniczną dotyczącą porzucenia odpytywania HTTP na rzecz WebSockets w czasie rzeczywistym w backendach gier.

---

Rozwiązanie wąskiego gardła DB: Wdrożenie pamięci podręcznej Write-Behind

Aby przetrwać setki tysięcy współbieżnych graczy aktualizujących statystyki, zarabiających walutę lub modyfikujących ekwipunek podczas meczów, nigdy nie wykonuj bezpośrednich zapytań SQL w pętli rozgrywki.

Zamiast tego zastosuj wzorzec buforowania Write-Behind (Write-Back). Modyfikacje stanu gracza są natychmiast aplikowane do szybkiego magazynu w pamięci (takiego jak Redis) i kolejkowane w asynchronicznym buforze. Dedykowany wątek w tle opróżnia zbatczowane mutacje do trwałości bazy danych co 5 do 30 sekund.

Implementacja produkcyjna w C#: Wysokowydajny bufor Write-Behind

Poniżej znajduje się gotowa do produkcji implementacja wątkowo bezpiecznego (thread-safe), zbatczonego bufora pamięci podręcznej write-behind, zaprojektowanego dla węzłów backendu gier o wysokiej współbieżności.

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;

public record PlayerStateMutation(string PlayerId, int CoinsGained, int MatchXp, DateTime Timestamp);

public class WriteBehindStateBuffer
{
    private readonly ConcurrentQueue<PlayerStateMutation> _mutationQueue = new();
    private readonly SemaphoreSlim _flushSemaphore = new(1, 1);
    private readonly CancellationTokenSource _cts = new();
    private readonly int _batchSize;
    private readonly TimeSpan _flushInterval;

    public WriteBehindStateBuffer(int batchSize = 500, int flushIntervalSeconds = 10)
    {
        _batchSize = batchSize;
        _flushInterval = TimeSpan.FromSeconds(flushIntervalSeconds);
        
        // Uruchomienie demona opróżniającego bufor w tle
        Task.Run(ProcessQueueLoopAsync);
    }

    /// <summary>
    /// Hot-path: Wywoływane przez logikę serwera gry podczas zdarzenia meczu.
    /// Nieblokujące dodawanie do pamięci (narzut 0.01ms).
    /// </summary>
    public void EnqueueMutation(string playerId, int coins, int xp)
    {
        var mutation = new PlayerStateMutation(playerId, coins, xp, DateTime.UtcNow);
        _mutationQueue.Enqueue(mutation);
    }

    private async Task ProcessQueueLoopAsync()
    {
        while (!_cts.Token.IsCancellationRequested)
        {
            await Task.Delay(_flushInterval, _cts.Token);
            await FlushBatchToDatabaseAsync();
        }
    }

    public async Task FlushBatchToDatabaseAsync()
    {
        if (_mutationQueue.IsEmpty) return;

        await _flushSemaphore.WaitAsync();
        try
        {
            List<PlayerStateMutation> batch = new(_batchSize);
            while (batch.Count < _batchSize && _mutationQueue.TryDequeue(out var mutation))
            {
                batch.Add(mutation);
            }

            if (batch.Count > 0)
            {
                await ExecuteSqlBatchInsertAsync(batch);
            }
        }
        catch (Exception ex)
        {
            // W produkcji: Zaloguj błąd, prześlij nieudany batch do kolejki awaryjnej (dead-letter)
            Console.WriteLine($"[CRITICAL] Write-Behind Batch Flush Failed: {ex.Message}");
        }
        finally
        {
            _flushSemaphore.Release();
        }
    }

    private async Task ExecuteSqlBatchInsertAsync(List<PlayerStateMutation> batch)
    {
        // Przykładowa symulacja wykonania jednej skonsolidowanej transakcji SQL
        // Zapytanie masowe (Bulk INSERT / UPDATE) zastępujące setki pojedynczych zapytań
        Console.WriteLine($"[DB FLUSH] Successfully written {batch.Count} state mutations to SQL in 1 transaction.");
        
        // Symulacja opóźnienia I/O bazy danych
        await Task.Delay(25);
    }

    public void Shutdown()
    {
        _cts.Cancel();
        FlushBatchToDatabaseAsync().GetAwaiter().GetResult();
    }
}

Dlaczego ta technika skaluje się?

• Redukcja zapytań: Zmniejsza 10 000 osobnych wykonań SQL typu UPDATE player_stats SET coins = coins + 50 do 1 zbiorczej transakcji w batchu.
• Zerowe opóźnienie wejścia: Klient otrzymuje natychmiastową informację zwrotną o sukcesie, ponieważ zmiana stanu jest rejestrowana w pamięci RAM natychmiast.
• Amortyzacja wstrząsów bazy danych: Jeśli ruch wzrośnie o 500%, obciążenie zapisu w bazie danych pozostanie płynne i stałe – rosną jedynie rozmiary kolejek w batchach.

---

Cykl życia serwera dynamicznego i optymalizacja zasobów

Gry imprezowe, tytuły typu social deduction oraz strzelanki lobby nie wymagają pełnej walidacji fizyki na poziomie 60 Hz, gdy gracze po prostu stoją w lobby przed grą i rozmawiają.

Aby maksymalizować gęstość serwerów na instancję chmurową, wdroż dynamiczne skalowanie częstotliwości (Tick Throttling):

+-----------------------------------------------------------------+
|                    CYKL STANU SERWERA                           |
+-----------------------------------------------------------------+

  [ LOBBY PRZEDGRYWE ] ----> [ AKTYWNA ROZGRYWKA ] ------> [ KONIEC MECZU ]
  - Częstotliwość: 10 Hz     - Częstotliwość: 30 - 60 Hz   - Częstotliwość: 5 Hz
  - CPU: ~5% rdzenia         - CPU: ~35% rdzenia           - CPU: ~2% rdzenia
  - Pasmo: Minimalne         - Pasmo: Wysokie              - Pasmo: Flush

• Faza lobby przed meczem (10 Hz): Niższa częstotliwość aktualizacji pozycji klientów i sprawdzania elementów kosmetycznych. To obniża zużycie procesora na pokój nawet o 65%.
• Faza aktywnej rozgrywki (30-60 Hz): Dynamiczne zwiększanie częstotliwości, gdy zaczynają się interakcje przestrzenne, głosowanie lub szybki ruch.
• Podsumowanie po meczu (5 Hz): Ograniczenie obliczeń serwera prawie do stanu bezczynności, gdy gracze sprawdzają nagrody, oszczędzając zasoby chmury przy jednoczesnym utrzymaniu otwartego gniazda WebSocket.

Więcej na temat tego, jak nowoczesne silniki zarządzają stanami bezczynności procesora i hibernacją serwerów w warunkach zerowego obciążenia, znajdziesz w naszej analizie architektonicznej poświęconej protokołom hibernacji serwerów o zerowym marnotrawstwie zasobów.

---

Budowanie własnej infrastruktury a infrastruktura zarządzana

Podczas skalowania architektury backendu gry multiplayer w celu obsługi nieoczekiwanych skoków ruchu, deweloperzy stają przed kluczowym wyborem infrastrukturalnym: zbudować niestandardowy backend skalowalny czy skorzystać z usług zarządzanych.

+-----------------------------------------------------------------------+
|                    STACK WŁASNEJ INFRASTRUKTURY                       |
+-----------------------------------------------------------------------+
| - Kubernetes Engine (Alokacja flot EKS / GKE)                         |
| - Integracja niestandardowego kontrolera Agones / Orkiestratora       |
| - Sharding rozproszonego klastra Redis Enterprise                     |
| - Niestandardowy silnik kolejki matchmakingu + Routing Edge           |
| - Potoki rozproszonego śledzenia Prometheus / Jaeger / Grafana       |
+-----------------------------------------------------------------------+
| SZACOWANY CZAS: 3 do 6 miesięcy pracy inżynieryjnej                   |
| NARZUT UTRZYMANIA: Ciągła inżynieria DevOps w gotowości bojowej        |
+-----------------------------------------------------------------------+

Zbudowanie całego tego potoku ręcznie wymaga konfiguracji niestandardowych klastrów Kubernetes, pisania alokatorów flot Agones, zarządzania shardowaniem klastra Redis oraz uruchamiania monitoringu DevOps przez całą dobę. Dla studiów niezależnych i średniej wielkości utrzymanie tej infrastruktury odciąga krytyczny czas rozwoju od faktycznych funkcji rozgrywki.

W tym miejscu dedykowane rozwiązanie Backend-as-a-Service, takie jak horizOn, zmienia doświadczenie dewelopera. Zamiast spędzać miesiące na budowaniu niestandardowych matchmakerów, flot socketów i dynamicznych autoscalerów serwerów, horizOn dostarcza gotowe, wstępnie skonfigurowane prymitywy backendu w czasie rzeczywistym – w tym natychmiastowe aprowizowanie sesji, skalowalną persistencję stanu oraz matchmaking o niskim opóźnieniu.

---

5 zasad projektowania skalowalnych backendów multiplayer

Jeśli obecnie projektujesz backend gry wieloosobowej, trzymaj te zasady w centrum swojego projektowania systemu:

1. Izoluj trwałą bazę danych: Nigdy nie pozwalaj tyknięciom serwera na żywo ani pętlom meczów czekać na bezpośredni synchroniczny zapis w bazie danych. Przekierowuj wszystko przez pamięci podręczne i asynchroniczne workery write-behind.
2. Projektuj pod bezstanowy routing brzegowy (Stateless Edge): Utrzymuj bramki API i proxy połączeń całkowicie bezstanowe. Jeśli bramka Node-A padnie pod obciążeniem, połączenia klientów powinny płynnie migrować do Node-B bez utraty podstawowego stanu sesji meczowej.
3. Dynamiczna alokacja zasobów: Dopasowuj częstotliwość tick rate serwera do stanu sesji gry. Nie marnuj cykli serwera na uruchamianie pełnych pętli gry podczas fazy lobby lub ekranów menu.
4. Używaj trwałych strumieni binarnych zamiast odpytywania HTTP: Przenieś komunikację na linii klient-backend z odpytywania HTTP REST na trwałe strumienie WebSockets lub gRPC, aby drastycznie ograniczyć narzut nagłówków i thrashing uzgadniania TCP.
5. Pracuj z gracją pod obciążeniem: Wdróż adaptacyjną degradację funkcji. Jeśli backend wykryje, że czasy w kolejkach rosną ponad progi bezpieczeństwa, automatycznie wyłącz nieistotne podsystemy (takie jak globalne tablice wyników matchmakingu lub podgląd niestandardowych kosmetyków), aby chronić rdzenne pętle meczów.

---

Następne kroki

Budowanie backendu multiplayer, który skaluje się do setek tysięcy współbieżnych graczy, nie polega na kupowaniu większych instancji w chmurze – polega na projektowaniu odsprzężonych, opartych na pamięci RAM architektur, które chronią bazę danych i optymalizują obliczenia sieciowe.

Jeśli jesteś gotowy wdrożyć odporny i skalowalny backend dla swojego kolejnego tytułu bez marnowania miesięcy na konfigurację flot serwerów i klastrów baz danych, sprawdź, jak horizOn może przyspieszyć Twoje wdrożenie. Możesz zarejestrować się, aby wypróbować horizOn za darmo lub zapoznać się z naszymi przewodnikami architektonicznymi w oficjalnej dokumentacji horizOn.

---

Źródło: Staying Lean: How We Built the World's Biggest Social Deduction Game