indexPresence, Salas y Fanout#presence#rooms#messaging#fanout
Esta nota todavía no está traducida, así que se muestra la fuente en inglés.

Presence, Rooms & Fanout

Where the previous branch built the mechanism (connections that can broadcast to each other without blocking), this branch designs what actually gets broadcast: rooms and channels, presence (who's online, and in which room), message history, and the guarantees a real chat needs to make about delivery — at-least-once vs exactly-once — and message ordering. It closes with the question every single-process design eventually hits: what happens when one server isn't enough, introduced through the pub/sub backplane concept (Redis Pub/Sub as the real-world answer, mentioned deliberately without being implemented in depth — it's the door into distributed infrastructure, not this atlas's destination).

Planned notes

  • Modeling rooms and channels: membership, joining/leaving, and what state that requires per connection
  • Presence: tracking who's online and where, and the update-storm problem when presence changes broadcast to everyone
  • Message history: what a "join a room mid-conversation" experience requires you to store and replay
  • Delivery guarantees: at-least-once vs exactly-once, and why chat usually settles for at-least-once plus client-side deduplication
  • Message ordering: per-room causal order vs global order, and what a network partition does to either guarantee
  • Fanout patterns: broadcasting one message to N room members without iterating a global connection list on every send
  • What breaks when a single server process can't hold all the connections and rooms anymore
  • The pub/sub backplane concept: how Redis Pub/Sub (or an equivalent) lets multiple server processes share room broadcasts
  • Where this atlas draws the line: the backplane is discussed and designed on paper (v5, optional), not built end-to-end — that's the start of distributed-systems territory
  • A written postmortem of a simulated multi-room, multi-hundred-connection load test

Core sources

  • Designing Data-Intensive Applications (Kleppmann) — the messaging/streaming chapters, for delivery guarantees and ordering.
  • Redis Pub/Sub documentation — the real-world backplane reference, mentioned not implemented.
  • Discord engineering blog, Slack engineering blog — documented, real chat-at-scale architecture decisions.

Connects to: Connection Concurrency at Scale · Client in C