Gaming Backend Platform

Topology Notes

• ·Game server instances are stateful at the connection layer (WebSocket connections are held) but stateless at the data layer (all durable state lives in Redis or PostgreSQL). The affinity router (consistent hashing on game_room_id) routes WebSocket upgrade requests to the instance owning the room. Once connected, the WebSocket connection persists on that instance for the room's lifetime. A NATS subject per room_id allows cross-instance state broadcasts when room membership spans multiple server instances (uncommon, but required for spectator modes).
• ·Redis holds two distinct data domains with different access patterns: (1) active game room state (hash per room_id, updated every tick, TTL = session_max_duration), and (2) matchmaking queues (sorted sets and lists per game mode and bracket, high throughput transient data). These must be separate Redis instances or Redis Cluster shards to prevent matchmaking throughput pressure from impacting game room state access latency.
• ·PostgreSQL serves the persistence layer for player profiles, inventory, achievements, and leaderboards. Leaderboard writes are the highest-frequency PostgreSQL operation (score updates at end-of-match); leaderboard reads are Redis-cached (sorted set per leaderboard, refreshed from PostgreSQL every 30s). Direct leaderboard reads from PostgreSQL are only for admin or audit use: player-facing leaderboard queries always hit Redis.
• ·Kafka carries post-game event streams to two independent consumers: the analytics pipeline (aggregates match statistics, player performance trends, game balance metrics) and the anti-cheat service (replays session events to detect anomalous action sequences using deterministic heuristics). Both consumers are read-only relative to the game server: they never write back to game state. Kafka topic retention is set to 7 days; completed session events are archived to cold storage on session close.
• ·Event sourcing snapshots are written to PostgreSQL at the end of every game session and at configurable intervals during long sessions. Snapshot writes are asynchronous relative to game tick: they do not block the game loop. The snapshot contains the full game state as of that tick; reconnecting players receive the latest snapshot plus a replay of subsequent events from the in-memory event buffer, targeting catch-up under 200ms.