Virtualize the private chat experience for multiple small groups of users on one Rocket.Chat instance

[Sing-Li]

We know one instance of Rocket.Chat can handle tens of thousands of users with ease already.

However, to provide Rocket.Chat service to a small group (5 users, say), it is still necessary to incur the cost of running a meteor and a mongo instance.

It would be ideal to be able to operate 2,000 private chats of 5 users each, on the same server/VPS config as the one that can handle a single 10,000 users public chat.

One solution is rely on post-docker hosting technologies like sandstorm.io that can freeze-dry and switch containers at a very high rate.

Another is to consider partitioning at the collection level. See the research link below, and an attempt by a community member to do something similar:

https://github.com/mizzao/meteor-partitioner

jaypanares@2b04cc4

Perhaps there are more alternatives.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rodrigok]

Interesting, something like add teams to rocket chat, right?

With this lib 1 user (email) can be part of only one group, so if I want to connect to more then one chat in the same instance I need to use 2 emails, right?

[Sing-Li]

idn, it would be ideal to somehow extend it to partition the user collection as well - more research than practical .. unless MDG would put it on their roadmap 😃

[Sing-Li]

hey ... can we 'virtualise' the real email + an appearance id ... and then gen a unique guid email to be used by meteor?? just a thought

the appearance id might just be a 'context identifier', from which white-labeled instance the user is logging in, for example:

(singli@hisemail.com + 'rocketchat team') -> kskfjsafosajdfasf@dsalfsakfaslf.com
(singli@hisemail.com + 'sings own family chat') -> o24i3i435o35345@oi324323432.com

[Sing-Li]

@jaypanares - would you mind sharing your operating experience with this lib. Are you running 24 7 , any problems?

[geekgonecrazy]

I think implementing teams would potentially be the first step to this.

If done right we could have the ability to isolate channels strictly to teams. Also allow just logging in to the team. A lot of customizations could be made using that approach.

Even if completely different instances I probably wouldn't have multiple mongo instances. Just multiple db's for each, and cluster the db's for redundancy. Need to measure.. but I wouldn't think rocket.chat would be too heavy to run multiple instances.

[liuliming2008]

How about:
1 a reg and longin instance
2 one email can create and join mutlple team, can switch to other teams after login
3 redirect teams(url, such as xx.rocket.com ) to different rocket chat instance(on the same host or not), instance connetted to one or more(if neccessary) db according the db config of these teams
4 dynamically migrate one team from one instance to another by the team members

I guess slack use the similar approach

[liuliming2008]

And:
1 one instance have reg,login,team creation and all rocket features
2 when app need to expand to more than one instance, just start one, and shift more chat traffic to he new one

[geekgonecrazy]

Some of this is being discussed over on #658

[engelgabriel]

Shoudl we close this and keep all the discussion on #630?