Practice/Uber/Design Messenger/Chat Application

Design Messenger/Chat Application

System DesignMust

Problem Statement

Design a messaging system like WhatsApp or Meta Messenger that supports real-time 1:1 chat, message delivery status tracking, and user presence features at scale. Users expect instant delivery, correct ordering, accurate status indicators (sent, delivered, read), and seamless multi-device continuity, even with flaky mobile networks.

The system must handle billions of users exchanging tens of billions of messages daily, with strict latency requirements (messages delivered in under 200 ms when both parties are online) and high availability expectations. It must gracefully handle network partitions, device failures, and bursty traffic patterns while maintaining message ordering and preventing duplicates.

Interviewers at Uber ask this because it probes your ability to design low-latency, highly available systems with billions of events, handle at-least-once delivery semantics, and reason about fan-in/fan-out patterns, presence, and synchronization across devices.

Key Requirements

Functional

• One-to-one messaging -- users send text messages to any contact with real-time delivery and clear sent/delivered/read status indicators
• Multi-device support -- conversations and message states remain consistent across all of a user's active devices (phone, tablet, desktop)
• Offline messaging -- users can compose and queue messages when disconnected; messages send automatically when connectivity resumes
• Presence indicators -- display whether contacts are currently online or show their last-seen timestamp

Non-Functional

• Scalability -- support 2 billion monthly active users sending 100 billion messages per day with peak traffic 3x average
• Reliability -- guarantee at-least-once delivery with no message loss; tolerate datacenter failures and network partitions
• Latency -- deliver messages end-to-end in under 200 ms for online users; presence updates propagate within 500 ms
• Consistency -- maintain strict message ordering within each conversation; eventual consistency acceptable for presence and read receipts

What Interviewers Focus On

Based on real interview experiences at Uber, Anthropic, and Meta, these are the areas interviewers probe most deeply:

1. Message Delivery Architecture and Ordering Guarantees

Interviewers want to see how you ensure messages arrive exactly once (from the user's perspective) in the correct order, even with network retries, multiple devices, and distributed infrastructure.

Hints to consider:

• Assign monotonically increasing sequence numbers per conversation to establish total ordering
• Use client-generated idempotency keys (UUIDs) to deduplicate retries at the server
• Partition message queues by conversation ID to preserve ordering guarantees
• Implement acknowledgment protocols where sender confirms receipt from infrastructure, and infrastructure confirms delivery to recipient

2. Real-Time Connection Management and Scaling WebSocket Infrastructure

A core challenge is maintaining persistent bidirectional connections for billions of concurrent users while routing messages efficiently. Interviewers probe how you distribute connection state and handle reconnections.

Hints to consider:

• Deploy a fleet of stateful WebSocket gateway servers with consistent hashing to distribute connections
• Store user-to-gateway routing information in Redis with TTL-based cleanup
• Implement heartbeat protocols to detect dead connections and graceful reconnection with sequence-number-based catch-up
• Use a pub/sub layer (Kafka, Redis Streams) to decouple message ingestion from connection fan-out

3. Multi-Device Synchronization and Conflict Resolution

When a user has multiple active devices, all must show the same conversation state. Interviewers look for explicit strategies to sync history, read receipts, and typing indicators.

Hints to consider:

• Maintain per-device read cursors (last seen message ID) in the database to track individual device state
• Use the maximum read cursor across all devices as the authoritative "read-by-user" timestamp
• Implement a sync protocol where devices fetch missing messages based on their last known sequence number
• Handle delivery receipts at the conversation level while tracking read receipts per device

4. Storage Strategy for Conversation History

Storing and retrieving message history efficiently at scale requires careful data modeling. Interviewers evaluate your choice of storage systems and partitioning approach.

Hints to consider:

• Model conversations as append-only logs with message ID, timestamp, sender, and content
• Partition by conversation ID and use time-based bucketing for archival
• Cache recent conversation windows (last 100 messages) in Redis with TTL eviction
• Implement pagination cursors for history retrieval rather than offset-based queries

5. Presence System and Last-Seen Tracking

Presence generates enormous write volume but has relaxed consistency requirements. Interviewers want to see how you optimize this high-frequency signal.

Hints to consider:

• Batch presence updates with a time window (5-10 seconds) to reduce write amplification
• Use a separate presence service with in-memory state and periodic persistence
• Implement subscription-based presence: only fan-out status to users who have the person in their contact list
• Accept eventual consistency for presence (delays of seconds are tolerable)