Design a Cross-Platform Chat Using MQTT

Problem statement

Design a cross-platform chat system — mobile, desktop, and web — that uses MQTT as the message transport. The platform must deliver one-to-one and group text messages, show who is online, provide delivered and read receipts, keep messages for offline users until they reconnect, synchronize history across devices, and do all of this over unreliable cellular and Wi-Fi networks with minimal bandwidth and battery cost.

MQTT was created at IBM in 1999 by Andy Stanford-Clark and Arlen Nipper to monitor oil-pipeline telemetry over lossy satellite links, and it was standardized by OASIS as MQTT 3.1.1 in 2014 and MQTT 5.0 in 2019. Its design goals — a minimal 2-byte fixed header, a persistent publish/subscribe session model, broker-side queueing for disconnected subscribers, and last-will notifications — are exactly the properties a mobile chat client wants. That is why Facebook's mobile chat used MQTT in the early 2010s, and why the protocol remains the default answer whenever bandwidth, battery, and flaky connectivity dominate the requirements.

Why this problem is distinctive

A typical interview answer reaches for WebSockets plus a homegrown connection layer. MQTT changes the shape of the design in four concrete ways. First, the broker owns connection state, subscriptions, and per-session offline queues, so the application tier stops being a stateful long-connection server. Second, topics — not endpoints — become the routing primitive, so conversation, group, presence, and control channels all need a deliberate topic taxonomy. Third, the protocol's QoS levels (0, 1, 2) interact with application-level acknowledgements, and getting that interaction wrong produces duplicates or silent loss. Fourth, broker fan-out makes group messaging cheap to express but moves the hard problems — ordering, membership checks, moderation — into the publish path.

The central architectural insight: the MQTT broker is a transport plane, not the system of record. Messages are durable in an application-owned store; the broker accelerates delivery and holds short-lived per-session queues. If the broker cluster dies, no committed message is lost; delivery merely pauses. If the store dies, chat stops, but no client silently loses history.

The four architectural planes

1. Client plane: mobile, desktop, and web SDKs with local storage, reconnect logic, and per-device identity.
2. Broker plane: a clustered MQTT broker fleet handling connections, subscriptions, QoS handshakes, retained messages, last wills, and session queues.
3. Application plane: chat services that authenticate, validate, persist, sequence, moderate, and fan out messages, plus presence, receipts, and notification services.
4. Data plane: message and conversation stores, presence cache, media object storage, analytics, and audit.

A strong answer keeps the planes separate. The broker never decides whether a user may read a conversation; the chat service never assumes a publish reached every subscriber; the client never assumes the broker queue is complete. Each plane fails independently and degrades without corrupting the others.