Design a Messenger-Style Chat Backend Without WebSockets or Persistent Connections

Design the backend for a chat product like Messenger. Users can start a one-to-one conversation, send text messages, receive messages from other people, and see their full conversation history on any device they sign in from. There is one deliberate constraint. The interviewer does not want a design built on WebSockets or any other persistent connection between client and server; clients talk to the backend only through ordinary request/response web APIs. How a client finds out that a new message has arrived is therefore part of the problem you must solve within that constraint. ### Constraints and Clarifications - No WebSockets and no other persistent bidirectional channel: assume every client interaction is an HTTP request that receives a response. - Messages must not be lost or duplicated, and both participants must see a conversation's messages in the same order. - A user can have several devices; every device should converge on the same history and read state. - No traffic numbers were given. Propose sizing assumptions and show which decisions they drive. - Media attachments, end-to-end encryption and voice or video calls are out of scope unless you choose to touch on them briefly. ### Clarifying Questions - Are group conversations in scope, and if so, how large can a group be? - Is a held HTTP request (long polling) acceptable, or does the constraint also rule out keeping a request open? - May the backend use the mobile platforms' push notification services to wake a device, or must everything go through our own APIs? - What delivery latency is acceptable when the recipient has the app open, versus when it is in the background? - Are delivery and read receipts, typing indicators or online presence required? - How long must history be kept, and can users delete messages? ### Part 1 — Requirements, APIs and data model State the requirements and assumptions you are designing for, the HTTP APIs a client uses, and how conversations and messages are stored. Walk through sending one message, from the sender's tap until the message is durably stored. ```hint Let the server order things Think about whose clock or counter decides the order of messages in a conversation, and what the client must send so that a retried send is not stored twice. ``` #### What This Part Should Cover - Functional and non-functional requirements with sizing assumptions - Request/response APIs for sending, fetching history and catching up - Storage layout and partitioning for messages and conversations - Message ordering and idempotent sends ### Part 2 — Delivering messages without persistent connections With WebSockets ruled out, explain how the recipient's devices learn about a new message, how quickly, and at what cost to the backend. Compare the options you considered and say which you would ship for an app in the foreground, in the background and offline. ```hint Make "nothing new" cheap Estimate how many check-for-new-messages requests the whole fleet would send per second, then ask what the backend has to do to answer the common case where nothing has changed. ``` #### What This Part Should Cover - At least two delivery mechanisms that fit the constraint, with their latency and cost - A per-user catch-up mechanism that guarantees no gaps after a missed signal - How empty checks stay cheap at scale - Behavior for foreground, background and offline devices ### Part 3 — Scaling and failure handling Scale the design to a very large user base. Cover fan-out to multiple devices, busy conversations, how each component can fail, and how you would find out. ```hint Follow one message through every hop List each step between the sender's request and the recipient's screen, and ask what happens if that step runs twice or not at all. ``` #### What This Part Should Cover - Partitioning and the write and read paths at scale - Reliable fan-out with at-least-once delivery and idempotent processing - Failure modes such as lost push signals, client retries and long-offline devices - Metrics that reveal slow or missing delivery ### What a Strong Answer Covers - Accepts the no-WebSockets constraint and designs within it instead of arguing for persistent connections - A clear source of truth for message order and for each device's sync position - A quantified comparison of short polling, held requests and push wake-ups - Cheap answers to the common empty check, backed by estimates - Durable, idempotent and gap-free delivery across devices - Senior-level ownership of trade-offs, failure handling and observability ### Follow-up Questions - Why might a team prefer request/response APIs over WebSockets for this product, and what does it give up? - How would you support group conversations with a few thousand members without multiplying write cost by the group size? - A device comes back online after a month away. How does it catch up without downloading everything or missing anything? - How would you add read receipts that stay consistent across a user's devices without doubling request volume?