ARE SLACK WORKSPACES PRIVATE CODE

ARE SLACK WORKSPACES PRIVATE CODE

This design was very simple and effective: To find data or send messages, our code only needed to look up the appropriate workspace’s shard and route the request there to verify that the requesting user had access to the given channel. In essence, the workspace was the unit of tenancy in the multi-tenant service, used for data partitioning and segmentation. The design also meant that application code interacting with a workspace’s content needed to first determine which workspace the request was for, and then use that context to route to a particular database or other server shard. This design allowed Slack to scale horizontally and onboard more customers by adding more server capacity and putting new workspaces onto new servers. Specifically, when a workspace was created, it was assigned to a specific database shard, messaging server shard, and search service shard. The backend systems used the boundaries of the workspace as a convenient way to scale the service, by spreading out load among sharded systems. They also provided the administrative and security boundary to implement access controls, as well as policy and visibility preferences. Basic Slack architectureįrom the time Slack was launched in 2014, this core system architecture centered around the concept of a “workspace.” Logically, workspaces enveloped all other objects in the system, including users, channels, messages, files, emoji, apps and more. The real-time message servers receive these new messages and send them to connected clients over web sockets, based on who is in the channel.

real-time message servers, which fan out messages, profile changes, user presence updates, and a host of other events to clientsįor example, a new message posted in a channel is sent via an API call to the webapp servers, where it is sent to the message servers and is persisted in the database.

webapp servers, which handle HTTP request/response cycles and communicate with other systems like the main databases and job queues.

Slack implements a client-server architecture where clients (mobile, desktop, web and apps) talk to two backend systems: Slack before shared channelsīefore we dive into shared channels, let’s take a look at how Slack works at a high level. We’ll talk about our initial architecture, the decisions that went into reframing how Slack worked, the implications of those decisions, and how we’re working on scaling for the future. For this post, we’ll discuss a few of the most interesting technical challenges from this change. The idea of shared channels challenged Slack’s fundamental assumption that the workspace is the atomic unit of partitioning customer data, however.

You no longer need to go back and forth between external emails and internal Slack channels, or provision an endless number of guests into your Slack workspace: A shared channel creates one productive space for people from both companies to send messages, share files, and work together in Slack. We’re now making shared channels available to all customers! A shared channel is one that connects two separate organizations.

As the network of companies using Slack for internal work grew, we saw the value of allowing different companies to collaborate together in one channel. Slack was originally built to be the collaboration hub for the work within your company. Written with contributions from the Shared Channels Team.

Are slack workspaces private