Loading…

Understanding the problem

A team chat product gives each company a workspace. People talk in public and private channels, in threads under a message, and in direct messages, on a laptop and a phone at once. Unlike a consumer messenger, the company owns the data: admins set retention, export history and search it, so messages are not end-to-end encrypted.

Confirm these in the first few minutes. Three carry the design: huge channels, badges that are right everywhere, and search that respects permissions.

Functional requirements

CoreSend and receive messages in public and private channels and direct messages, within a company’s workspace.
CoreReply in a thread under any message, and follow the threads you care about.
CoreSee which channels have unread messages and where you were mentioned, the same on every device you use.
CoreSearch your workspace’s history, and only ever see messages from channels you are allowed to see.
CoreEdit or delete your own messages.
CoreShare files of up to 1 GB in a channel.
CoreSee whether a colleague is online.
CoreAdmins set how long messages are kept, place legal holds and export their workspace’s history.
Below the lineTyping indicators.
Below the lineEmoji reactions.
Below the lineScheduled messages and reminders.
Below the lineCustom emoji.
Below the lineVoice and video calls.A separate media system.
Below the lineApps and bots.They post through the same API with their own limits.
Below the lineRanking search results by relevance.Matching and permissions come first; ranking can follow.
Below the lineGuests.The same channel model with outside members and narrower access.

Non-functional requirements

DurabilityA message the service has accepted is not lost before the workspace’s configured retention expires, and while retained it appears once on every device.
ConsistencyEveryone sees a channel’s messages in the same order, on every device.
LatencyA message to someone who is online arrives within about 500 ms at the 99th percentile.
ConsistencyUnread badges and mentions are right on every device within a few seconds.
SecuritySearch answers within about a second, and never shows a message from a channel the searcher can’t see.
Availability

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 200,000 workspaces; the largest has about 300,000 members.
ScaleAbout 30 million people active on a weekday, each in about 50 channels; most use a laptop and a phone.
ScaleAbout 500 million messages a day, busiest on weekday mornings in each time zone.
ScaleA company-wide channel can have 100,000 members.
ScaleThe biggest customers keep 10 years of searchable history.

Out of scope

Out of scopeBilling and sign-up.
Out of scopeSpam and abuse detection.

Check yourself

Why can’t this product be end-to-end encrypted the way a messenger is?
Show answerHide answer
The company, not just the people talking, owns the messages: admins need export, retention and legal holds, and search runs on the server.
Which requirement decides how messages are delivered?
Show answerHide answer
The biggest channel: a post to a hundred thousand members has to reach everyone online within about half a second without a write per member.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Rounded figures, one line of working each. Messages are few compared with deliveries, badges and history.

Back of the envelope for team chat

Quantity	Value	Working
Messages, day average	About 6,000 a second	500 million over 86,400 seconds, from the brief.
Messages, morning peak	About 17,000–30,000 a second	3–5× the average when offices open (the practice sample uses 5×).
One post in #announcements	About 30,000 deliveries	100,000 members, about 30% online.
Member-channel pairs	At least 1.5 billion	30 million weekday-active people in about 50 channels each; inactive members add more.
Ten years of history	At most about 1.8 trillion messages, about 1.8 PB	If all 500 million a day were kept 3,650 days at about 1 KB each; only the biggest customers keep that long, so the real total is lower before replicas and indexes.
Cursor moves at the peak	Up to about 50,000 a second	If all 30 million people were online at once, each reading a channel about every 10 minutes; an upper bound.
Index growth	About 500 GB a day	500 million messages at about 1 KB indexed each.

Architecture diagramWhere the load lands

Try it: The numbers that shape the designGuided practice · Chat, Team chat · Senior

Check yourself

Which number rules out writing a copy of each message per member?
Show answerHide answer
The 100,000-member channel: each post would be 100,000 writes, for a single message.

Core entities

A workspace has channels; a channel has messages in number order. A membership row says who is in a channel, and also where they have read up to and how many times they were mentioned since. A thread reply is a message that names its parent.

The entities and their key fields

Entity	Key fields	Why it exists
Workspace	id, name, plan, retention policy, home cell	The tenant: limits, rules and placement.
Channel	id, workspace, public or private, latest number	Where messages are ordered and delivered.
Membership	channel, member, read cursor, mention count	Permissions and badges.
Message	`channel_id`, `seq`, `client_msg_id`, author, text, parent (for replies)	Stored once, ordered by `seq`.
Member	id, workspace, devices	Who receives pushes and where.
Thread follow	thread (parent message), member, read cursor	Who hears about replies, and their unread state.

Architecture diagramWorkspaces, channels, and where a member stands in each

Diagram as text

Components: Workspace (SQL DB); Channel (public or private) (SQL DB); Message (channel, seq) (SQL DB); Member (SQL DB); Membership (cursor, mentions) (SQL DB); Thread reply (parent) (SQL DB). Connections: Workspace → Channel (public or private) (has); Channel (public or private) → Message (channel, seq) (in order); Member → Membership (cursor, mentions) (joins); Membership (cursor, mentions) → Channel (public or private) (of); Message (channel, seq) → Thread reply (parent) (thread).

Read:Learn: Data model design Learn: Partitioning, sharding and consistent hashing

Try it: Workspaces, channels and messagesGuided practice · Chat, Team chat · Senior

Keep reading+1 min

Where cursors live

Membership rows are read on every app open and written on every read, so they sit in a fast key-value store keyed by member, with the database as the record of truth. A member’s cursors for all their channels come back in one read, which is what makes a slim start-up view cheap.

Check yourself

Where does a member’s badge for #release come from?
Show answerHide answer

The API

Clients send through an HTTP API and receive over one websocket. Every send carries an id the app made, so a retry returns the stored message instead of posting it twice. History is fetched per channel “after number n”, which is also how a device catches up. Sending over the websocket instead, as the practice sample does, works equally well; what matters is the app-made id.

The main calls

Call	Request	Reply
Send	`client_msg_id`, channel, text, parent if a reply	The stored message with its `seq`
History	channel, after `seq` or before `seq`, limit	Messages in order
Mark read	channel, `seq`	The new cursor, pushed to the member’s other devices
Search	query, filters	Matches from channels the member can see
Websocket events	One connection per device	New messages, edits, cursors, typing

Read:Learn: API contract design Learn: Idempotency and retries

Try it: What travels on the connectionGuided practice · Chat, Team chat · Senior

Keep reading+1 min

Apps and bots

Apps post through the same send call with their own tokens and per-app limits, and receive events through a webhook or a socket of their own. Treat them like members with stricter caps: a misbehaving bot should hit its own limit, not slow the workspace it lives in.

Check yourself

The send call times out and the app retries. What stops a duplicate post?
Show answerHide answer
The retry carries the same client message id, so the server finds the stored message and returns it.

High-level design

Build the design one flow at a time: a message reaching everyone in a channel, then a device opening the app and catching up. The deep dives harden each part.

A message in #general, end to end

The app sends the message to the API, which stores it in the channel’s shard with the channel’s next number and only then confirms it. The API hands it to the channel’s server.

The channel’s server sends one copy to each gateway with members of the channel online, and each gateway writes it to those members’ sockets.

Asha sends with her app’s message id.
The API stores it with #general’s next number.
The channel’s server sends it to each subscribed gateway.
Each gateway writes it to its members’ sockets.

Architecture diagramA message in #general, end to end

The API stores the message with the channel’s next number, then hands it to the channel’s server, which sends it once to each gateway that has a member of the channel online. Each gateway writes it to its members’ sockets.

Diagram as text

Components: Asha’s laptop (Client); Messages API (Service); Channel’s shard (SQL DB); Channel server (Service); Gateway, Mumbai (API gateway); Gateway, London (API gateway); Members online (Client). Connections: Asha’s laptop → Messages API (send, with its own id); Messages API → Channel’s shard (next number); Messages API → Channel server (stored); Channel server → Gateway, Mumbai; Channel server → Gateway, London; Gateway, Mumbai → Members online (sockets).

Read:Learn: Real-time delivery architecture Learn: Consistency trade-offs

Try it: A message in #general, end to endGuided practice · Chat, Team chat · Senior

Check yourself

Why store before handing the message to the channel’s server?
Show answerHide answer
So that a crash can’t leave a message some people saw and nobody can scroll back to.

Opening the app, and catching up

A device loads a slim start-up view, the member’s channels with their latest numbers, and opens a websocket; its gateway subscribes to the channel servers for those channels. For each channel it opens, the device fetches everything after the last number it has.

The app loads a slim start-up view.
Its gateway subscribes to the member’s channels.
Opened channels fetch everything after the device’s last number.

Architecture diagramOpening the app, and catching up

Design a Slack-style team chat

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

Where cursors live

The API

Apps and bots

High-level design

A message in #general, end to end

Opening the app, and catching up

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

Where cursors live

04The API

Apps and bots

05High-level design

A message in #general, end to end

Opening the app, and catching up

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this