Design a 1-1 Chat Within a Social Platform

Problem statement

Design the private direct-messaging subsystem of a large social platform: two users exchange text, emojis, and images in a thread that persists across devices, years, and network failures. The feature looks simple—'send a text'—but it is actually three systems welded together. First, a durable ordered log per conversation that never loses an acknowledged message and paginates history fast. Second, a real-time delivery fabric that pushes new events to online devices within a few hundred milliseconds and reconciles offline devices when they return. Third, a trust and privacy boundary: private chat logs are among the most sensitive data a platform holds, so security, moderation, and retention are architecture concerns, not afterthoughts.

Why this is distinctive

A news feed is tolerant: a missing post is invisible to the user. A chat is intolerant: a missing, duplicated, or reordered message is immediately visible to both participants, and a leaked log is a front-page incident. Therefore the design must guarantee per-conversation ordering and at-least-once delivery with idempotent apply, while simultaneously treating ephemeral signals—typing, presence, receipt pings—as disposable traffic that must never contend with durable writes. The second distinctive property is the read/write shape: unlike feed fan-out to thousands of followers, a 1-1 message fans out to exactly one recipient plus that recipient's devices, which makes per-conversation partitioning natural but multi-device sync the real complexity.

Public operating baseline versus design assumptions

Public figures establish the category's scale. WhatsApp reports on the order of 100 billion messages per day across 2B+ users on an Erlang-based fleet. Discord's engineering blog describes storing trillions of messages, first in Cassandra and later in ScyllaDB, with an Elixir gateway holding millions of concurrent sockets. Slack has described per-tenant MySQL shards and WebSocket channel servers for 10M+ daily active users. Facebook Messenger has publicly described an MQTT-based sync layer and a full client/server rebuild (Project Lightspeed) to shrink sync payloads. These are cited company figures, not requirements for our design.

For capacity planning this answer explicitly assumes a mature social platform with 200M MAU, 100M DAU, 40M peak concurrent online sessions, and 2B messages per day with a 3x peak multiplier. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Client plane: mobile/web clients with local outbox, retry, cursor pagination, and offline cache.
2. Real-time transport plane: WebSocket/MQTT gateways, connection registry, presence, ephemeral event routing, sync on reconnect.
3. Durable messaging plane: conversation log, inbox projections, sequence allocation, media store, push notification pipeline.
4. Trust plane: encryption and key management, moderation pipeline, retention and deletion, audit.

A strong interview answer keeps these planes separate: the transport plane may lose a socket without losing a message, and the trust plane constrains both without sitting inline on the hot path.