Meta·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

System design round at Meta for a software engineering role. The whole session was basically one big question about building a real-time 1-to-1 messaging system, and they pushed hard on every layer of it.

Questions Asked (1)

Design a 1-to-1 chat application at the scale of something like WhatsApp or Messenger, covering real-time messaging, presence, read receipts, push notifications, and message history.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

I started with WebSockets vs SSE and the interviewer let me run with it for a while, which felt like a good sign.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying functional and non-functional requirements, then estimate scale (e.g., 2B users, 100B messages/day) to drive design decisions. Architect a high-level system with separate services for messaging, presence, notifications, and storage, and dive deep into critical components like message delivery guarantees and storage schema. Discuss trade-offs (e.g., consistency vs. availability, push vs. pull) and how to handle scale, failures, and real-time updates.

Pro tip: Emphasize idempotency and message ordering—these are often overlooked but critical for a reliable chat system at scale. Also, proactively discuss how you would handle offline users and message synchronization across multiple devices.

1. Requirements and Scale Estimation

Clarify functional requirements (1-to-1 chat, real-time, presence, read receipts, push notifications, history) and non-functional (low latency, high availability, consistency). Estimate scale: daily active users, messages per second, storage needs, and connection counts.

2. High-Level Architecture

Sketch the main components: clients, WebSocket gateways for real-time connections, chat servers, message queues, databases (for messages and metadata), presence service, notification service, and push notification gateways. Explain data flow for sending and receiving messages.

3. Deep Dive into Key Components

Detail the design of critical parts: message storage (e.g., wide-column store like Cassandra for messages, Redis for presence), message delivery guarantees (at-least-once, idempotency, ordering), read receipts (tracking and propagation), and push notifications (integration with APNs/FCM).

4. Scalability and Reliability

Discuss how to scale horizontally: partitioning messages by conversation or user, sharding databases, using consistent hashing for chat servers, handling millions of concurrent connections, and ensuring fault tolerance with replication and failover.

5. Trade-offs and Optimizations

Address trade-offs: consistency vs. latency for read receipts, push vs. pull for message sync, storage costs vs. retention. Mention optimizations like batching, compression, and caching.

Key Points to Mention

Use WebSockets for real-time bidirectional communication, with a gateway layer to manage connections and scale horizontally.
Store messages in a distributed database like Cassandra, partitioned by conversation ID, with time-based ordering and efficient retrieval for history.
Implement presence using a heartbeat mechanism and a fast in-memory store like Redis, with pub/sub for updates.
Ensure message delivery reliability with idempotent message IDs, acknowledgments, and retries; handle offline users via message queues and push notifications.
Design read receipts as a separate lightweight service that updates message status and notifies participants, considering eventual consistency.
Leverage push notification services (APNs, FCM) for offline users, and handle multi-device synchronization with per-device message queues.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.