To implement a slack bot, i need to deal with 'Real Time Messaging API' of slack. It is a WebSocket-based API that allows you to receive events from Slack in real time and send messages as user. more info: https://api.slack.com/rtm
To create a bot for only one team, i need to open one websocket connection and listen it for events.
To make available the slack bot for another team. I need to open a new websocket connection. So,
- 1 team => 1 websocket connection
- 2 teams => 2 websocket connections
- N teams => N websocket connections
what should i do to scale my websocket connections for endless teams?
What kind of architecture can handle autoscaling of 1000’s of websockets connections?
With slack sockets, you have lots of things to scale:
The other thing to consider is fault-tolerance. Let's say you did sticky load balancing and one of your servers is handling 50 teams. That server is the only one handling those 50 teams so if it goes down then all 50 bots go offline. Alternatively, you can open up multiple sockets per team on separate servers and use a message handling queue so that each message is only responded to once.
So the architecture I would propose is a thin, redundant load balancer for RTM sockets as a first layer, and a reliable message queue underneath that.