1.000 Transaktionen pro Sekunde: Die Architektur hinter unserem Remote Game Server

Von allen Systemen, die wir entwickeln und betreiben, hat unser Remote Game Server (RGS) die kompromisslosesten Anforderungen. Er ist das Herzstück im Online-Gaming: die Komponente, die Spielrunden ausführt und jede einzelne Transaktion verbucht — Einsatz, Gewinn, und wenn etwas schiefgeht, den Rollback. Bis zu 1.000 solcher Transaktionen pro Sekunde, und hinter jeder steht echtes Geld. Dieser Artikel beschreibt, welche Architekturentscheidungen aus diesen Anforderungen folgen.

Die Anforderungen, die alles bestimmen

Ein RGS sitzt zwischen den Spiele-Clients und der Plattform des Betreibers. Aus dieser Position ergeben sich drei Anforderungen, die sich gegenseitig im Weg stehen könnten — und genau deshalb die Architektur formen:

1. Korrektheit ist nicht verhandelbar. Bei Spielen mit echtem Geld gibt es keine „ungefähr richtige” Buchung. Jede Runde muss exakt einmal verbucht werden — auch wenn mittendrin eine Verbindung abreißt oder ein Server neu startet.
2. Latenz ist Produktqualität. Ein Spieler wartet nach dem Klick auf das Ergebnis. Jede Millisekunde im kritischen Pfad ist spürbar; das Budget für eine Transaktion liegt im einstelligen Millisekundenbereich.
3. Nachvollziehbarkeit ist Pflicht. Die Branche ist reguliert. Jede Runde muss sich im Nachhinein lückenlos rekonstruieren lassen — wer hat wann was gesetzt, was wurde ausgezahlt, was zurückgerollt.

Go in den heißen Pfaden

Für die performance-kritischen Services des RGS setzen wir auf Go — eine Entscheidung, die in unserem Tech-Radar seit Jahren im Adopt-Ring steht. Die Gründe sind dieselben, über die wir hier schon 2019 geschrieben haben, nur unter Last noch einmal deutlicher: Go-Services starten schnell, brauchen wenig Speicher, und das Nebenläufigkeitsmodell mit Goroutines passt natürlich zu einem System, das viele kleine, unabhängige Spielrunden gleichzeitig abwickelt. Ein vorhersagbarer Garbage Collector und schlanke Binaries machen das Verhalten unter Spitzenlast kalkulierbar — und Kalkulierbarkeit ist in diesem System wichtiger als jede Peak-Benchmark-Zahl.

Redis: der Zustand im Spielpfad

Im kritischen Pfad jeder Runde steht der Spielzustand: Sitzung, laufende Runde, aktueller Kontostand der Interaktion. Dafür nutzen wir Redis als Key-Value-Store. Die Begründung ist schlicht — Zugriffe in Mikrosekunden statt Millisekunden, einfache Datenstrukturen, vorhersagbares Verhalten. Der Spielpfad liest und schreibt Zustand, ohne auf eine relationale Datenbank zu warten.

Genauso wichtig ist die Abgrenzung: Redis ist bei uns der Ort für den schnellen Zustand, nicht für die Wahrheit. Die dauerhafte, nachvollziehbare Verbuchung jeder Transaktion geschieht in der persistenten Datenhaltung dahinter — dort, wo Auditierbarkeit zu Hause ist. Diese Trennung — schneller Pfad und Buchführung als getrennte Verantwortungen — ist die vielleicht wichtigste Einzelentscheidung der Architektur.

Die schwere Hälfte: korrekt unter Fehlern

1.000 Transaktionen pro Sekunde klingen nach einer Durchsatz-Aufgabe. Tatsächlich ist der Durchsatz die einfachere Hälfte — Go und Redis liefern ihn fast nebenbei. Die schwere Hälfte heißt: 1.000-mal pro Sekunde korrekt sein, auch wenn etwas schiefgeht.

Drei Prinzipien tragen das:

• Idempotenz überall. Jede Transaktion trägt eine eindeutige Identität. Kommt dieselbe Anweisung doppelt an — weil ein Client neu sendet oder ein Timeout zuschlug —, wird sie genau einmal wirksam. Wiederholen ist im System immer sicher.
• Der Rollback ist eine Operation erster Klasse. Eine abgebrochene Runde ist kein Sonderfall, der in einem Log landet, sondern ein definierter Geschäftsvorfall mit eigener Transaktion. Wer Rollbacks als Ausnahme behandelt, hat bei Echtgeld schon verloren.
• Nichts Unkritisches im kritischen Pfad. Alles, was nicht zur Entscheidung der laufenden Runde gehört — Auswertungen, nachgelagerte Verarbeitung, Benachrichtigungen — verlässt den Pfad asynchron. Entkopplung über Messaging gehört bei uns ohnehin zum Standardwerkzeug; hier ist sie die Voraussetzung dafür, dass das Latenzbudget hält.

Dass zertifizierte Zufallszahlengeneratoren und unabhängige Prüfungen in dieser Branche zum Standard gehören, sei der Vollständigkeit halber erwähnt — sie sind die Eintrittskarte, nicht die Kür.

Was wir daraus mitnehmen

Der RGS ist unser bestes Beispiel dafür, dass Architektur aus Anforderungen folgt und nicht aus Vorlieben: Go nicht, weil es modern ist, sondern weil Vorhersagbarkeit unter Last zählt. Redis nicht als Datenbankersatz, sondern als bewusst begrenzter Zustandsspeicher. Und der meiste Entwurfsaufwand steckt nicht im Glücksfall, sondern im Fehlerfall — Idempotenz, Rollbacks, Wiederanlauf. Mit über 75 Jahren kollektiver Erfahrung im Online-Gaming im Team wissen wir: Genau dort entscheidet sich, ob ein System mit echtem Geld vertrauenswürdig ist.