hard meta · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: 1:1 and group messaging, message delivery/read receipts, online presence, offline message delivery when a user reconnects.
- Non-functional: low latency delivery, message ordering per conversation, durability (messages shouldn’t be lost), scale to millions of concurrent connections.
Core components
- Connection layer: WebSockets (persistent, bidirectional) rather than polling — a fleet of connection servers, each holding many open sockets, with a routing layer to find which server holds a given user’s connection.
- Message flow: sender → connection server → message service (persists to DB, assigns sequence number) → look up recipient’s connection server (via a presence/session store) → push to recipient if online, else queue for offline delivery.
- Storage: a database optimized for the access pattern “get recent messages for a conversation” — often a wide-column store partitioned by conversation ID.
- Presence service: tracks which users are online and which connection server holds their socket.
Key tradeoffs
- Message ordering per conversation is easier to guarantee with a single sequence source per conversation than globally.
- Exactly-once delivery is hard; most real systems accept at-least-once + client-side dedup (via message IDs) as the practical answer.