Realtime Backend System Design with WebSockets

If we know the limitations of a protocol we can use it effectively.

This is an IO intensive , so we don't need as many backends so backends can be built in a mesh architecture.

No load balancing, client picks the server, only rooms within the server can be used.  No database, very simple.

Pros, simple

Cons, can't chat with other servers, no load balancing (one server can get overloaded if the url is shared)

Load balanced at stream level, client connects to the closest gateway, fleet of backends per gateway. a pub/sub to relay messages.

Client sends a message streamed through gateway streamed through a backend, a backend writes it to the pub/sub and all backends subscribe to the pub/sub, message pushed to all backends subscribed. queue room number.

Pros: Can chat with other all rooms, load is balanced

Cons: Complex, more components, resource intensive (streaming)

WS application load balancing, h2 web sockets or even shared web sockets (less connections more streams) , gateways. Still pub/sub

Pros: Better resource usage (compare to Design 2) , load balancing

Cons: Complex more components, Backend implementation is tricky (h2)

Because we don't anticipate lots of backends. We can drop the pub/sub and have the backends talk to each other directly.

WS application load balancing, h2 web sockets or even shared web sockets (less connections more streams) , gateways. 

Pros: Better resource usage (compare to Design 2) , load balancing

Cons: Less complex than Design 3, ditched the pub/sub system

• Gamers join an interactive World game

• Gamers interact with objects to “break”

• Breaking an item gets XP based on the item

• Only one gamer gets the XP (last one that destroy it)

• All game World must update in real-time

CPU intensive, game need to scale

When a player make a move or attack, a ws msg is sent, the new game state is calculted and the diff is sent to  all players get the new state. Or we can send the moves and have the clients calculate the state.

No load balancing, locality and lowest latency. Clients pick the server. You can only join games in the same server you connect to. Simple design. We can restrict the number of players per game and restrict players accordingly (each box can handle x concurrent games)

When a player make a move or attack, a ws msg is sent, the new game state is calculated and the diff is sent to  all players get the new state. Or we can send the moves and have the clients calculate the state. The moves are labeled and ordered by arrival time.

No need for a database

Pros: Low latency

Cons: A single Server can be overloaded if too many players join

Load balancer that is game aware when a game is created it will pick a server.

Players who want to join to the same game will "land" on that server.

Pros: Scalable

Cons: Need more components, we need to see All active games, we need to a database to store games.