In a team chat product, a message posted to a channel with 8,000 members must reach everyone connected. Design the delivery path.

What the interviewer is testing

Whether you separate persistence, fan-out and connection management, and whether you recognise that most members are not connected.

The observation that shapes the design

Only a fraction of members are connected at any moment. Fan-out to 8,000 people is really fan-out to the few hundred with an active connection, plus a durable record for everyone else to read when they return.

Designs that treat delivery as "push to 8,000" do enormous unnecessary work.

The path

Persist first. The message is written durably and assigned a monotonic position within the channel. This is the source of truth, and everything else is a delivery optimisation. If delivery fails, the message is still there and the client reconciles on reconnect.

Publish to the channel's topic. Connection servers holding sessions for members of that channel subscribe, and each pushes to its own connected clients over their WebSocket.

The routing question is which connection servers care. Maintaining channel-to-server subscriptions avoids broadcasting every message to every server — which matters enormously, since without it each server processes all traffic rather than its share.

Clients reconcile on reconnect by requesting everything after their last known position. This is what makes the push path best-effort rather than guaranteed, which is a much simpler system to build.

The hard parts

Connection state. Hundreds of thousands of long-lived WebSocket connections is a distinct scaling problem — memory per connection, load balancer limits, and the reconnect storm when a connection server dies and all its clients reconnect simultaneously. Jittered reconnect backoff is mandatory.

Unread counts and read state, which are per-user-per-channel and change constantly. This is frequently a larger data problem than the messages.

Very large channels, where fan-out to a single popular channel dominates. The same skew problem as social feeds.

What a strong answer adds

Ordering guarantees stated explicitly: ordering within a channel is what users perceive, and it comes from the monotonic position assigned at persistence rather than from delivery order. Cross-channel ordering is not guaranteed and does not need to be.

And the client model: the client is not a passive recipient but a reconciling participant holding a position and requesting what it missed. That assumption removes a great deal of delivery complexity.

Common weak answers

Guaranteed delivery to every member. Broadcasting every message to every connection server.