Few-to-many architecture: pipeToRouter, or 1 router per worker?

I’ve read up quite a bit on pipeToRouter, but am having difficulty wrapping my head around it. Although after typing this up, I’m not even sure I need it.

For context, my primary goal is supporting 250 consumerUsers (500 consumers) consuming 4 separate audio+video producerUsers (8 producers). Later I will need to support 1,000+ consumerUsers, but baby steps…

My current setup is as follows (and is working great for small audiences):

  • 1 worker per “room” of users.
  • 1 router per worker.
  • producerUsers have 1 send transport, 1 receive transport.
  • consumerUsers have 1 receive transport only.

To accomplish my goal of 250 consumerUsers in a room with 4 producerUsers, I plan on changing to:

  • 4 workers per “room”, each is dedicated to 1 of the 4 producerUsers.
  • 1 router per worker.
  • producerUsers have 1 send transport, 4 receive transports.
  • consumerUsers have 4 receive transports only.
  • Each receive transport maps to a different router / producerUser

Would this be the advised configuration? Are there any examples of how pipeToRouter might be relevant here, either now or as I grow to 500 consumerUsers; 1,000 consumerUsers, etc.?

It seems like for my use-case, I’ll always need a 1:1 ratio of 1 router for each worker, because both routers and workers can handle roughly 500 consumers. I can’t for the life of me think of a good scenario in which pipeToRouter would be needed.

You said “I will need to support 1,000+ consumerUsers” so you’ll need pipeToRouter().

  • Run a worker with a single router_1 for the 4 producers.
  • Run N workers with a single router_N each.
  • Pipe the Producers in router_1 to all router_N.
  • In each router_N add up to 500 Consumers.
1 Like

Okay, I think I follow. So router_1 will just have 8 producers for the 4 producerUsers, and 0 consumers.

Then I will pipe router_1 to all router_Ns, which is where the consumer webRtcTransports will be created? And I can consume/subscribe to producers via each router_N exactly the same as if everybody were on router_1?

Very cool. I will try this tomorrow. Thank you.

As far as you call router1.pipeToRouter({ router: routerN, producerId: xxxxx }) for all Producers in router1, yes.

1 Like

Thanks, this is working great :+1:

The docs seem to say workers/routers are only limited in the # of consumers they can handle (~500), and there’s no limit on # of producers. Is this correct? Having 30 producerUsers on a single worker should be fine if only a handful of consumerUsers subscribe? (and the producerUsers don’t subscribe to each other).

Also, for any future readers:

This isn’t what I ended up doing; I think my initial understanding was incorrect. My app does put all 8 producers on router_1, but I also add up to 500 consumers to it. Then I start assigning consumers to the next router/worker, and the next one, etc.

Rather than maxing a single worker out at 500 before moving to the next one, I opted for a round robin approach, because I imagine it’s better to have 4 cpus at 10% capacity rather than 1 cpu at 95% capacity and 3 cpus at 0%. But that’s just my gut talking…I have no idea if it makes a difference.