Design Messenger/Chat Application
Design a messaging system like WhatsApp or Facebook Messenger that supports real-time 1:1 chat, message delivery status tracking, and user presence features at scale.
Asked at:
Meta
Uber
Airbnb
Amazon
A messenger is a real-time chat and contact platform where people exchange direct messages, see when friends are online, and keep conversations in sync across phones, tablets, and the web—think WhatsApp or Facebook Messenger. The core user expectations are instant delivery, correct ordering, accurate status indicators (sent, delivered, read), and seamless multi-device continuity, even with flaky mobile networks. Interviewers 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. You’re expected to translate ambiguous requirements into a robust architecture, make principled trade-offs, and demonstrate pragmatic scaling strategies without over-engineering.
Hello Interview Problem Breakdown
Design WhatsApp
System design answer key for designing a messaging application like WhatsApp, built by FAANG managers and staff engineers.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to send and receive 1:1 messages with near real-time delivery and clear sent/delivered/read status.
Users should be able to manage contacts (search, add/remove, block) and start conversations from their contact list.
Users should be able to use the app across multiple devices with conversation history and message states kept consistent.
Users should be able to continue composing and sending messages offline, with automatic retry and delivery when connectivity returns.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
In messaging, exactly-once delivery is impractical over mobile networks, so you need to design for at-least-once with idempotency. Interviewers look for clear, per-conversation ordering and a reconciliation strategy when devices go offline and reconnect. - Use server-assigned, per-conversation sequence numbers and idempotent message IDs so you can safely retry without duplicates. - Keep per-device checkpoints/high-watermarks and let devices request backfills since the last checkpoint to recover gaps after reconnects. - Bound reordering by sharding on conversationID and processing in-order within a shard; resolve conflicts with server sequence + ingestion time.
Low-latency delivery and presence are table stakes for a chat app and a common focus in a system design interview at Meta or Uber. You need a plan for connection management, update coalescing, and efficient push for backgrounded mobile apps. - Use regional connection gateways with WebSockets for foreground sessions and fall back to push notifications for backgrounded devices; route users to the nearest region via an anycast or Geo-DNS strategy. - Store session/presence in an in-memory store and broadcast via pub/sub with heartbeats and timeouts; coalesce rapid presence changes to reduce update storms. - Apply connection-level rate limiting and backpressure; batch small messages/acks to stay under tail latency targets during bursts.
Users expect every device to reflect the same conversation state. Interviewers want to see device identity, versioning, and deterministic conflict resolution, not hand-wavy "we sync it somehow." - Give each device a unique identity and maintain device-specific cursors; sync deltas since the last cursor and paginate backfill for large histories. - Define clear conflict rules (e.g., last-writer-wins using server sequence for edits/deletes; aggregate receipts from devices to a user-level state on the server). - Support selective history sync and compression to manage bandwidth; on device unlink, revoke keys/cursors and force a fresh resync.
Storage can dominate cost and performance in a messaging system. Interviewers look for thoughtful data modeling, sharding, and lifecycle management that still preserves low-latency reads. - Model messages in a wide-row schema partitioned by conversationID with time clustering; use TTLs, cold storage tiers, and compaction to reduce hot storage costs. - Consider per-user or per-conversation retention policies and efficient deletion workflows (soft-delete + async purge) to meet privacy requests. - Keep secondary indexes minimal; if search is needed, stream to a separate index (e.g., Elasticsearch) via a log, avoiding hot partitions on the primary store.
Relevant Patterns
Relevant patterns that you should know for this question
Chat depends on bi-directional, low-latency updates for messages, presence, typing indicators, and read receipts. WebSockets plus pub/sub are essential to push changes immediately to online devices and keep state in sync.
Even in 1:1 chat, peak traffic creates intense write loads (bursts, retries, acks). Sharding by conversation, batching, and log-based ingestion let you absorb spikes, maintain ordering, and keep tail latencies low.
Users frequently load conversation history across devices. Read caches, partitioning for hot conversations, and pagination are necessary to deliver fast history queries without overloading primary storage.
Relevant Technologies
Relevant technologies that could be used to solve this question
Similar Problems to Practice
Related problems to practice for this question
It is the closest analog: direct messaging with delivery/read receipts, multi-device sync, and massive scale. The same ordering, idempotency, and low-latency fan-out concerns apply.
Both require real-time fan-out of short messages/updates with strict latency budgets and techniques to avoid hot partitions during spikes (events, live streams).
While the data model differs, both need real-time presence, conflict resolution, and multi-client state convergence where clients reconnect and reconcile changes.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Hand-waving delivery semantics (no clear ordering, deduplication, or retry strategy)
Without explicit at-least-once delivery, idempotent writes, and per-conversation ordering, users will see duplicates, missing messages, and inconsistent receipts across devices.
Single hot partition or monolithic message table for all conversations
Concentrating writes and reads on one partition creates hotspots and high tail latencies. Large or active conversations will overwhelm the system and cause outages under bursty traffic.
Vague multi-device sync with no per-device cursors or conflict rules
Saying "we sync across devices" without device identities, checkpoints, and deterministic conflict resolution leads to message gaps, incorrect read states, and confusing user experiences.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late September, 2025
Meta
Mid-level
Mid September, 2025
Meta
Senior
Early September, 2025
Microsoft
Mid-level
Your account is free and you can post anonymously if you choose.