Evaluating Colyseus: Questions About Scalability

[cort1c]

Hello all. I'm currently evaluating Colyseus for a new project and I have some questions about how it's intended to be scaled. I read the Scalability page in the documentation and maybe I'm missing something but it feels a little thin. I have a few questions for anyone that has experience scaling Colyseus or at least understands how it's meant to work at some level.

1. The documentation mentions running multiple processes of Colyseus behind a load balancer. Is the idea to just randomly distribute connections across N nodes?
2. If so, how would I go about getting different players into the same room so they can send/receive messages if they're connected to different nodes?
3. The documentation mentions Presence as a key feature for scalability but doesn't really explain how it's intended to be used. I see that it's basically a wrapper around the Redis API but that doesn't explain much.
4. For matchmaking, is there a way for the Matchmaker API to make reservations on other nodes? I would normally think about a matchmaker as an independent process that routes one or more clients to a different game server node. As is, it feels like the Matchmaker API is intended to just route users connected to that node to locally hosted rooms.

Thanks in advance for any answers or even just providing hints about other places to look for more information.

[endel]

Hi @cort1c, I'm glad you're considering Colyseus for your next project!

There is some relevant information on how to configure scalability on this thread, with participation from @joshestein @bwasia and @zack1991

---

Let me go over your questions, I agree current documentation is not great, an extended version of this needs to be documented there soon (I've been quite busy preparing updates for Colyseus Cloud lately 🙈...)

---

1. The documentation mentions running multiple processes of Colyseus behind a load balancer. Is the idea to just randomly distribute connections across N nodes?

Not really. In short, match-making requests may arrive at any process. The match-making response contains a roomId / sessionId and publicAddress - which the client uses to connect directly to the process where the room is really located.

2. If so, how would I go about getting different players into the same room so they can send/receive messages if they're connected to different nodes?

The client connections are distributed to the correct Node.js process where the room you're requesting lives at. It is important to have the publicAddress configured, and have each Node.js process publicly accessible via its own URL, so clients can be forwarded accordingly.

3. The documentation mentions Presence as a key feature for scalability but doesn't really explain how it's intended to be used. I see that it's basically a wrapper around the Redis API but that doesn't explain much.

The Presence is used internally by the framework for inter-process communication (pub/sub). A remote process may request another process to create and/or reserve a seat in an existing room in another remote process.

4. For matchmaking, is there a way for the Matchmaker API to make reservations on other nodes? I would normally think about a matchmaker as an independent process that routes one or more clients to a different game server node. As is, it feels like the Matchmaker API is intended to just route users connected to that node to locally hosted rooms.

Yes, but the framework does not currently provide a way for you to manually tell which server to use. New rooms are always created in the process with the least amount of rooms.

---

Let me know if you have any questions or need me to clarify any of this.

---

(@joshestein @bwasia @zack1991 please feel free to collaborate on the discussion if you'd like to 🤗)

[cort1c]

Thank you very much for the information. That was incredibly helpful and pretty much answered all of my questions. Sorry it took me a couple of days to circle back and read your post. :)