FastPubSub Network

Resilient realtime pub/sub over the global Internet

Realtime infrastructure for game developers

Player-visible networking does not forgive stalls. FastPubSub keeps session traffic flowing when Internet paths fail — the mesh reroutes in seconds; stale samples are dropped, not buffered.

It is not a game server. It is the live message transport between players, services, and regions when direct Internet paths are too uneven.

FastPubSub Overlay Net Player Group A Edge Relay Overlay Core Edge Relay Player Group B Measured overlay path (lower jitter) Direct Internet path (route instability)

Where multiplayer messaging gets hard

Jitter shows up immediately

Movement, presence, matchmaking, and session events feel rough when timing swings from one tick to the next.

Players arrive through messy networks

Different ISPs, mobile carriers, cloud regions, and peering paths can make one match feel different for every player.

Replay is not the hot path

For fast coordination, the important message is the one that reaches the session now, not the one stored perfectly for later.

What changes with FastPubSub

Route around bad hops

When a path degrades, the overlay reroutes in seconds. Relays measure RTT, jitter, and loss continuously — session traffic keeps moving instead of stalling behind retries.

WebSocket-compatible edge

Clients and game services can use WebSocket today while the relay backbone moves traffic over QUIC.

Fan out closer to players

Messages are distributed near subscribed player groups instead of forcing every update through a central bottleneck.

Channel permissions for rooms and pairs

Issue scoped tokens that define who may publish to each channel and who may listen: player-to-player sessions, party rooms, spectators, match services, or backend-only control channels.

game-dev peer projects rooms

Tenant isolation for rooms and environments

Keep games, customers, rooms, test environments, and production traffic separated with tenant boundaries, independent channel namespaces, and scoped access tokens.

game-dev peer projects staging/prod

Common session traffic

Shared state

Position, presence, lobby, and room state updates for active sessions.

Server events

Match updates, countdowns, score changes, and authoritative notifications sent to players.

Player signals

Client events forwarded to coordination services, observers, or regional processors.

Good fits and wrong jobs

Good fits

  • Real-time game state delivery
  • Session coordination and live player events
  • Peer-style rooms with scoped publish and subscribe tokens
  • Separate tenants for games, customers, rooms, and environments
  • Cross-region messaging with lower jitter

Not meant for

  • Authoritative game server replacement
  • Strict ordered gameplay stream processing
  • P2P mesh networking between players

See why this managed service is not Kafka, NATS, or RabbitMQ software →

Related solutions

Give multiplayer messages a better path

Start with WebSocket-compatible pub/sub and route live session traffic around unstable Internet paths.