Hello,

I have a web-based game platform that relies on WebSockets. In this game, up to 10 gamers can join a match together (but not necessarily at the same time. Some can join first, and others can join later) to play a game against each other. There can be more than tens of thousands of players playing the game at the same time, but only 10 players max per match/room.

I have been using a default load balancer service provided by my cloud platform which distributes user connection to one of many available HTTP servers in the backend. When 10 users, who are in the same room, end up in different backend HTTP servers, the servers communicate with each other using Messaging platform (Something similar to Apache Kafka) to relay and communicate actions happening within a room.

Things are working fine, but this approach has few issues.

• Messaging platform can become a bottleneck when we scale. (It gets worse as we increase # of HTTP servers)
• Messaging platform adds latency in edge cases.
• Messaging platform adds cost.

Therefore, I am looking for a solution to see if I can somehow route users who are supposed to be in the same room to the same backend game server in one go. If all users/players from the same room are connected to the same server, there is no more need for an inter-server messaging platform.

Of course, I could potentially separate my current server which is doing both HTTP handling & Game logic into two sets of servers, one set for Frontend HTTP Servers and the other set for Game Servers like below.

From

x WebSocket Clients ←--→ y (HTTP & Game) Servers ~~~~ MessageQueue platform

To

x WebSocket Clients ←--→ y HTTP Servers ←--→ z Game Servers

With the latter approach, I could have more fine control of maintaining a set of game servers.. but it will require some substantial dev effort on my end to change current architecture like that. Additionally, the assignment of room/matches to the z Game servers is still a problem to solve.

Therefore, I am looking for a way to solve this problem without making substantial changes to the system if possible. (Perhaps, with the use of some smart reverse-proxy load-balancer or framework in front of HTTP servers?)

My requirements would be something like

1. If no player has joined for a room or match A1 yet, then the first player to join can end up in any one of the backend HTTP servers.
2. When there is at least one player already connected to backend server S1 for match A1, some mechanism should forward later joining players to server S1.
3. The number of backend servers up and running can change any time before/during/after when 1 and 2 are happening.

If anyone has insights on this or advice to give… please let me know.

@hplus0603 Thank you so much for the guidance. I think what you said will likely work for my case.

if you want to do dedicated player allocation, you need to have something that knows how to allocate and route those

I was kind of hoping for shortcuts, but that does make sense. At least, it will be a fun problem to solve.

So in summary, if I use a path-based routing approach over DNS, I will have to do… (I am running backend in Kubernetes)

1. Build a room tracker service to keep track of (room, serverIP:port) mappings.
2. Learn & figure out dynamically updating path-based routing for reverse proxy at runtime.
3. Use path-based routing to direct/relay users to the correct serverIP:port.
4. Figure out a good way to discover newly added hosts in Kubernetes when scaling up servers. (or vice versa when scaling down or replacing hosts)

I think the trickiest part for me is #4, and #1,#2,#3 all depend on #4, but I will do some research and see how it goes.

P.S. I really wish I can take a look into Fortnite's backend source code someday to understand how they handle 100 users per match for millions of concurrent users.