Building real-time servers for on-chain games

Shared rounds, live chat and presence all need a connection that stays open and answers in milliseconds. Our real-time layer is built for that, and for staying healthy when a few clients misbehave.

WebSockets only

Our gateway speaks WebSockets and nothing else. There is no long-polling fallback to maintain or attack. Messages are capped at 16 KB, and a heartbeat every 25 seconds clears out dead connections quickly.

Admission before the handshake

Before a connection is accepted, the gateway checks that it comes from one of our own sites. Then each connection has to take a lease: a slot recorded in Redis by a single atomic script, with caps per network address and per account. Leases expire on their own after 45 seconds unless renewed, so a crashed server never leaves ghost connections holding slots.

Event budgets

Every address and every account gets a budget of events per 10-second window. Each event also has a one-second deadline and runs under a concurrency limit. One noisy client can use up its own budget, but it can't slow anyone else down.

One session, rechecked

A socket authenticates with the same session as the website. The gateway keeps rechecking that session while the socket is open, and closes the connection as soon as the session expires or is revoked. Signing out really does sign you out everywhere.

Scale out, not up

Game servers share events through a Redis adapter, so any server can deliver a message to any player. Adding capacity means adding instances, not rewriting anything.

Chat that moderates itself

Before a chat message is broadcast, it goes through automated moderation. Text is normalized and lookalike characters are folded together, so swapping in look-alike letters doesn't slip past the filters. Matching runs as a single pass over every pattern at once, so it stays fast as the lists grow.