Katkat
Back

Design a One-on-One Chat Service

AnthropicSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a highly available, low-latency one-on-one messaging system capable of delivering messages in real time, maintaining strict ordering, and handling offline synchronization.

Scenario

Design a scalable one-on-one instant messaging platform (similar to WhatsApp or Slack Direct Messages). The service must support real-time communication between pairs of users, store conversation history reliably, and provide delivery guarantees even when recipients are offline or switching devices.

Requirements

Functional Requirements

  • 1-on-1 Real-Time Messaging: Users can send and receive text messages in real time with sub-second latency.
  • Message Status: Support delivery statuses: sent (server received), delivered (recipient device received), and read (recipient viewed).
  • Chat History & Sync: Users can scroll back through past messages and synchronize history across multiple client reconnects.
  • Offline Support: If a recipient is offline, messages must be persisted and delivered as soon as they reconnect, with mobile push notifications sent in the interim.

Non-Functional Requirements

  • Low Latency: Real-time message delivery latency under 100ms globally when both users are online.
  • Consistency & Ordering: Messages within a conversation must appear in strict chronological order on both devices.
  • Durability & Reliability: Zero message loss once acknowledged by the server (at-least-once delivery guarantee to the client).
  • High Availability: 99.99% uptime for core messaging path.

Scale Assumptions

  • Daily Active Users (DAU): 50 million
  • Message Volume: 1 billion messages per day (~12,000 messages/second average, ~30,000 peak)
  • Message Size: Average text message payload is 200 bytes (plus metadata)
  • Storage Growth: ~250 GB/day of new message data, requiring scalable partitioning

What to Cover

  1. API & Connection Protocol: Choice between WebSockets, gRPC, and HTTP long-polling for bi-directional communication.
  2. System Architecture: Component breakdown including connection managers (session/gateway servers), message ingestion pipeline, presence tracking, and push notification services.
  3. Data Model & Storage: Database selection (e.g., Wide-column NoSQL vs. Relational) and schema design for messages, conversation indexes, and message sequence tracking.
  4. Message Flow & Guarantees: Step-by-step lifecycle of a message from sender to receiver, including deduplication and offline handling.
  5. Trade-offs: Latency vs. consistency, connection registry scalability, and ordering strategies (e.g., distributed IDs vs. per-conversation sequence numbers).

Hints

Hint 1

Differentiate the data paths for active real-time message streaming (stateful WebSocket connections) and message persistence (stateless writes to durable storage).

Hint 2

For message ordering, consider why simple wall-clock timestamps can be problematic across distributed clients and how conversation-scoped sequence numbers or distributed ID generators (like Snowflake) solve this.

Hint 3

Decouple message delivery from storage using a distributed pub/sub or message broker (e.g., Kafka or Redis Streams) so that slow receivers or bursts do not degrade the ingestion layer.

Follow-up questions

  • How does the architecture adapt if users can be logged in concurrently on multiple devices (e.g., phone, desktop, and tablet)?
  • How would you implement end-to-end encryption (E2EE) using the Signal Protocol, and what responsibilities shift away from your backend?
  • How would you handle massive spikes in read receipts without overwhelming the persistent storage layer?