Slack just lately printed the way it sends tens of millions of real-time messages each day throughout the globe. The corporate offers a complete perception into its Pub/Sub structure, designed to handle real-time messages at scale. It highlights the distinctive challenges posed by delivering real-time messages throughout totally different time zones and areas and the way Slack’s engineers designed the infrastructure to deal with them.
Sameera Thangudu, Senior Software program Engineer at Slack, explains the significance of this structure:
Our servers serve tens of tens of millions of channels per host, tens of tens of millions of related purchasers, and our system delivers messages internationally in 500ms. With the linear scalability of our present structure, our projections present that we are able to serve many extra clients.
She states that the corporate plans to boost its structure to serve a extra vital buyer base.
The system’s backend consists of a number of providers. Channel Servers (CS) are stateful, in-memory servers holding channel historical past. A constant hashing mechanism maps every CS to a subset of channels. At peak instances, every host serves about 16 million channels. Constant hash ring managers (CHARMs) handle the constant hash ring for CSs, making certain the alternative of unhealthy CSs inside 20 seconds. Consul shops the up-to-date configuration of constant hashes.
Supply: https://slack.engineering/real-time-messaging/
Gateway Servers (GS), like CSs, are stateful, in-memory servers. They preserve person info and WebSocket channel subscriptions and act as an interface between Slack purchasers and CSs. GSs are deployed throughout a number of geographical areas to optimize connection speeds. Admin Servers (AS) are stateless, in-memory servers that interface between the Webapp backend and CSs. Lastly, Presence Servers (PS) monitor on-line customers, powering the inexperienced presence dots in Slack purchasers.
Each Slack consumer has a persistent WebSocket connection to Slack’s servers to obtain real-time occasions to take care of its state. The consumer units up a WebSocket connection via a number of steps, corresponding to fetching the person token and WebSocket connection setup info from the Webapp backend. Then the consumer initiates a WebSocket connection to the closest edge area, and GS fetches person info and sends the primary message to the consumer. Envoy load balances incoming visitors and handles TLS termination.
Supply: https://slack.engineering/real-time-messaging/
As soon as the consumer setup is full, every message despatched in a channel is broadcasted to all purchasers on-line within the channel. Messages journey via Webapp API, AS, and CS earlier than being despatched to each subscribed GS worldwide. Every GS that receives the message sends it to each related consumer subscribed to that channel ID.
Supply: https://slack.engineering/real-time-messaging/
Other than chat messages, occasions are one other message sort that adjustments the consumer’s state in real-time. Transient occasions, corresponding to a person typing in a channel, observe a barely totally different movement since a database doesn’t persist these occasions. The diagram under illustrates this movement.
