Design Messenger

Problem Design a Messenger-style chat system: 1:1 and group conversations, delivery/read receipts, online presence, durable history.

Functional requirements

• Send/receive in 1:1 and group chats; message states sent → delivered → read per recipient; presence (online/last-seen); history sync across devices; offline users get messages on reconnect.

Non-functional requirements

• Delivery latency < ~200 ms online; no message loss (at-least-once + client dedupe); scale to discuss: tens of millions concurrent connections, high write volume.

Key components

• Gateway layer holding persistent WebSocket connections; session/registry service (user → gateway); chat service assigning per-conversation sequence ids; message store (wide-column, partition by conversation_id cluster by seq — Cassandra-style); per-device delivery queues for offline sync; receipt pipeline (delivered/read events flowing back); presence service (heartbeats → TTL'd status, fanned out to friends with damping); push notifications for closed apps.

Deep dives / trade-offs

• Ordering: per-conversation monotonic seq (single writer per partition) vs timestamps (skew); why global ordering is unnecessary.
• Group fan-out: write once per conversation + per-member cursors, vs materializing per-member queues — read vs write amplification.
• Presence at scale is the hidden hard part: heartbeat interval vs staleness, fan-out storms on flapping connections, subscribe-on-view rather than push-to-all.
• Read receipts in groups (per-member watermark seq, not per-message rows).