Katkat
Back

Design One-to-One Messaging Across Multiple Devices

LyftSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Tests the ability to architect a real-time, one-to-one messaging system supporting multi-device synchronization, push notifications, idempotent message delivery, and reliable cursor-based history pagination.

Scenario

Design a reliable, low-latency one-to-one messaging service (such as in-app communication between riders and drivers, or peer-to-peer customer support). Users can access their accounts across multiple concurrent devices (e.g., primary phone, backup tablet, or web browser). When a message is sent, all devices belonging to the sender must reflect the sent state, and all devices belonging to the recipient must receive the message in real time or receive a push notification if offline.

Requirements

Functional Requirements

  • 1:1 Messaging: Users can send text messages to another user with low latency.
  • Multi-Device Sync: Messages sent from one device must sync to all other devices owned by the sender and recipient.
  • Delivery & Read States: Support message state tracking (sent, delivered, read) across all active devices.
  • Offline Fallback: If a device is disconnected or in the background, deliver an alert via mobile push notifications (APNs/FCM).
  • History & Pagination: Clients can fetch past messages deterministically without skipping or duplicating items during ongoing chats.
  • Retry Safety: Network interruptions and client retries must never result in duplicate messages displayed to users.

Non-Functional Requirements

  • Latency: Real-time message delivery under 150 ms globally for online users.
  • Availability: 99.99% availability for the messaging backbone.
  • Consistency: Strong ordering per conversation; at-least-once transport combined with idempotent client processing.

Scale & Numbers

  • DAU: 50 million daily active users.
  • Volume: 500 million messages per day (~6,000 messages/sec average, 25,000 peak).
  • Concurrency: Up to 10 million simultaneous persistent connections.
  • Devices: Average of 2 registered devices per active user.

What Your Design Should Cover

  1. API & Data Model: Define endpoints for sending messages and fetching conversation history. Propose a database schema, partition keys, and ordering mechanisms.
  2. High-Level Architecture: Detail the flow between connection gateways, session registries, message storage, and notification pipelines.
  3. Multi-Device Synchronization: Explain how the system routes messages to multiple active sessions per user and how read receipts propagate.
  4. Pagination Strategy: Design a stable pagination scheme that handles concurrent message insertion.
  5. Failure Modes & Edge Cases: Address client reconnection, message deduplication, and out-of-order delivery.

Hints

Hint 1

Use a unique client-generated deduplication ID combined with a monotonically increasing sequence ID per conversation to guarantee idempotency and strict ordering.

Hint 2

Decouple persistent connection management from business logic by maintaining a session registry (e.g., Redis cluster) that maps user IDs to multiple active gateway socket addresses.

Hint 3

Avoid offset-based pagination for chat history; use cursor-based pagination backed by a composite index of conversation ID and message sequence ID or 64-bit time-ordered ID.

Follow-up questions

  • How would you adapt this design to support end-to-end encryption (E2EE) across multiple devices without sharing private keys over the network?
  • If a recipient's connection drops intermittently during message bursts, how do you prevent duplicate push notifications while ensuring zero lost messages?
  • How does your schema handle conversation list rendering (inbox view with last message, unread count, and sender) without performing expensive aggregations on every open?