Design Slack

A message is sent to a channel (not a person) and latecomers must read it later. What happens to it?

1. Rejected. Push it to currently-connected members and forget it.

   Fire-and-forget loses the message for anyone offline, on another device, or joining later — and there’s no scrollback. Chat’s value is the durable, organized record.

2. Rejected. Store a copy per user who should receive it.

   Copying a message into every recipient’s mailbox explodes storage for big channels and complicates joins/leaves and ordering. Model the channel, not N recipient copies.

3. The call. Persist to a per-channel store, then deliver.

   The channel service looks up members and writes the message to ordered per-channel history first, so latecomers and other devices always get a complete record. Persist first, deliver second.

Messages must appear the instant they’re sent. How does the server reach the right client live?

1. Rejected. Clients poll the API every second for new messages.

   Polling is laggy and wasteful — most polls return nothing, and "live" still feels a second behind. To feel instant the server must push, not wait to be asked.

2. The call. Persistent WebSockets + a session registry mapping user→server.

   Each client holds a long-lived socket to a gateway; a registry records which server holds each user’s connection, so "deliver to user U" becomes "push on this socket on this server" instantly.

3. Rejected. Email or SMS each new message.

   Wrong channel and far too slow for live chat, and unboundedly noisy. Out-of-band notifications are for offline users (step 6), not the real-time path.

A channel’s members are spread across many gateway servers. The receiving server only knows its own clients. How does everyone get the message?

1. Rejected. Have each gateway query every other gateway for recipients.

   All-to-all gateway chatter is O(servers²) and tightly couples them — adding a server means rewiring everyone. You want one publish, not a mesh of point-to-point calls.

2. The call. Publish each message to a pub/sub Message Bus that all gateways subscribe to.

   The sending gateway publishes once; every gateway subscribed to that channel pushes to its local sockets. One publish reaches members on any server, and gateways become interchangeable subscribers you can add freely.

3. Rejected. Route all of a channel’s users to one gateway server.

   Pinning a whole channel to one server creates hotspots (a huge channel overwhelms it) and breaks when users are in many channels on different servers. Bridge servers with a bus instead.

Green dots and "Bob is typing…" fire constantly and are disposable. How do you handle them?

1. Rejected. Write each presence/typing event to the message store.

   Persisting a flood of high-frequency typing events would swamp the durable store with data nobody reads back. Presence is throwaway — it shouldn’t touch message storage at all.

2. Rejected. Send typing events through the same path as messages.

   Mixing high-frequency disposable signals into the durable pipeline risks the thing that matters (messages) during a presence storm. Keep them on separate paths.

3. The call. A separate ephemeral path: in-memory presence, broadcast, never persisted.

   Track online/away/typing in fast ephemeral storage and broadcast over the same sockets, but never store it. If everyone disconnects, presence simply vanishes — and a typing storm can’t risk the message store.

Teams accumulate millions of messages and need to find old ones by keyword. How?

1. Rejected. Scan the message store for the keyword on each search.

   Scanning years of history per query is far too slow. You need a structure built for retrieval, not a linear scan of the raw store.

2. The call. Build an inverted Search Index at write time, enforce permissions on read.

   Index messages as they’re written so queries hit the index, not the raw store — and scope results to channels the user can access. Permissions must be part of the query, not an afterthought.

3. Rejected. Let each client cache and search its own messages.

   Clients hold only a sliver of history and can’t search what they never received or channels they just joined. Search must run server-side over the full indexed record.

Every device must show accurate unread counts and badges, consistently. How do you compute "unread"?

1. Rejected. Store an unread counter per user per channel and increment it.

   A raw counter drifts across devices and is hard to keep consistent (which device decremented?). It also can’t say which messages are unread, only how many — fragilely.

2. Rejected. Recount unread messages from the store on every open.

   Re-scanning a channel’s history to count unreads on every app open is wasteful at scale. There’s a cheap derivation if you track one marker instead.

3. The call. Store a per-user, per-channel last-read cursor; unread = messages after it.

   Unread is just "messages after my last-read marker" — cheap to compute, and syncing that one cursor across devices keeps every client in agreement automatically.