As real-time multiplayer games scale globally, traditional networking models strain under the weight of low-latency expectations, compliance constraints, and unpredictable player distribution.
In this article, I explore how event-driven pub-sub architectures—when used in combination with channel partitioning, broker layering, and latency-aware routing—can transform matchmaking systems into scalable, resilient, and globally accessible infrastructures.
The approaches outlined are the result of several years of designing and deploying real-time backend systems in commercially successful casual and card-based multiplayer titles.
Why the Industry Must Move Beyond “Simple Matchmaking”
Most mobile game backends still rely on monolithic matchmaking servers or naive queue systems that assume geographic proximity, uniform latency, and stable server access. This assumption breaks quickly in the real world:
- Players join from latency-diverse regions.
- Firewall and compliance restrictions limit access to certain data centers.
- Peak traffic leads to queue bottlenecks or match churn.
To address this, we must shift our mental model: matchmaking is not a linear process but a dynamic, multi-stage pipeline with decision points that must adapt in real-time.
The Role of Pub-Sub in Modern Multiplayer Infrastructure
Unlike point-to-point sockets or REST APIs, Publisher-Subscriber (pub-sub) systems allow for:
- Asynchronous orchestration of lobbies, match state, and player intents.
- Loose coupling between clients, game instances, and orchestration logic.
- Multi-region message routing without overloading origin servers.
In this model, every stage of the player experience is event-driven. From lobby discovery to move submission, events are published into topic-based or fanout channels that handle routing and transformation transparently.
Architecture Pattern: Lobby Sharding via Dynamic Channels
In our real-world deployments, we evolved a sharded matchmaking architecture that assigns players to lobbies via dynamic pub-sub channels. Here’s how it works:
- Ingress Gateway receives a play request and publishes a “join request” to a region-specific matchmaking topic.
- A matchmaker service (stateless, horizontally scalable) subscribes to this topic and routes the player to a lobby shard—an ephemeral pub-sub channel.
- Once a shard reaches quorum (e.g., 4 players), the service publishes a start_game event to all subscribed clients.
- Each client then transitions to a real-time game session managed through a dedicated match state topic.
This pattern allows us to scale matchmaking independently of game sessions and to apply custom logic (like ELO balancing, latency optimization, or anti-cheat profiling) before match formation.
Cross-Region Broker Mesh: Solving the “Blocked Server” Problem
A more advanced challenge we solved relates to cross-border compliance and failover. In regions where access to foreign cloud infrastructure is restricted (e.g., certain CIS countries), we use a broker mesh:
- Regional players connect to local edge brokers.
- Those brokers are part of a layered pub-sub topology where key match topics are relayed securely across borders via encrypted tunnels.
- This prevents blocked regions from becoming matchmaking dead zones without forcing all data through a central backbone.
We built a latency-aware relay controller that dynamically determines whether to match players locally, route through intermediary nodes, or exclude incompatible regions—ensuring compliance without compromising UX.
Key Lessons from Production Use
Across millions of sessions and real cash-based PvP matches, a few insights stand out:
- Topic hygiene is critical. Auto-expiring or ephemeral topics prevent memory leaks and ghost players.
- Broker selection matters. Redis PubSub is simple but lacks ordering and delivery guarantees; NATS and Kafka offer more control at the cost of setup complexity.
- Observability should be built-in. Every message event must be traceable—OpenTelemetry helped us root out subtle desyncs and timeouts.
- Client-side fallbacks are non-negotiable. When pub-sub fails (e.g., flaky mobile networks), clients gracefully degrade to polling-mode recovery.
Moving Toward Fully Serverless Orchestration
We’re now exploring a serverless-first architecture for future games, where
- Matchmaking logic is expressed as event-driven functions (e.g., AWS Lambda, GCP Cloud Functions).
- Lobby orchestration runs on stateless containers that spin up per region during load spikes.
- Pub-sub remains the core fabric for matchmaking and in-game messaging, abstracting away the complexities of infrastructure routing.
This reduces cold-start time, simplifies deployment pipelines, and makes it viable to support millions of daily matches with lean operational overhead.
Conclusion
Pub-sub isn’t just an implementation detail—it’s an opportunity to reshape how multiplayer games scale, adapt, and survive under modern conditions.
By applying it not only to gameplay but also to lobby orchestration, regional compliance, and matchmaking resilience, we unlock a new generation of mobile experiences that are real-time, fair, and globally available by design.
The article is op-ed authored by Andrei Kulakov
Andrei Kulakov is a systems architect and game designer with a focus on multiplayer infrastructure for mobile and casual games. He’s contributed to some of the most technically robust matchmaking frameworks in Eastern Europe and is currently exploring serverless architectures for global multiplayer at scale.
This story was originally published on 3 October 2022
Directly in Your Inbox
