Design One-to-One Chat
Company: Anthropic
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a scalable one-to-one chat system.
Scope:
- Only direct one-to-one messaging is required.
- Group chat, public channels, workspace features, and threaded conversations are out of scope.
Your design should cover:
1. Core user flows for sending and receiving a message.
2. Message persistence and retrieval.
3. Delivery when the recipient is online.
4. Delivery when the recipient is offline.
5. How the system detects whether a user is online.
6. How client sessions and WebSocket connections are stored and managed.
7. Ordering, retries, deduplication, and delivery acknowledgements.
8. The tradeoffs between using Kafka and Redis in the design.
9. The internal principles of Kafka that matter for this system, such as partitions, ordering, offsets, and consumer groups.
State your assumptions about scale, latency, and reliability requirements before presenting the design.
Overview: This question evaluates expertise in designing scalable, real-time one-to-one messaging systems, testing knowledge of distributed systems principles, message persistence and retrieval, delivery semantics, session and WebSocket management, ordering, retries, deduplication, and trade-offs between streaming and in-memory technologies such as Kafka and Redis. It is commonly asked to assess architectural reasoning about latency, availability, ordering guarantees and reliability within the System Design domain, and requires a mix of conceptual architectural understanding and practical implementation-level considerations.
Read the full Anthropic Software Engineer interview experience this question came from
Community answers
Answer by 404NotFound
In this chat architecture, Presence and the Session Registry work together in Redis, but they track two different levels of information to solve the routing problem.
Here is the breakdown of the difference:
Presence (The "Who" and "How Many")
The Presence key maps a User ID to a Set of Session IDs.
What it answers: "Is this user online right now, and if so, how many devices do they have open?"
How it works: If User B is logged in on both their iPhone and their MacBook, their Presence record (presence:{UserB}) will contain two distinct session IDs.
Online Status: The system considers a user "Online" as long as their Presence set has at least one active, non-expired session ID in it.
Session Registry (The "Where")
The Session Registry maps a Specific Session ID to an Exact Gateway Node.
What it answers: "For this exact connection, which physical server is holding the WebSocket?"
How it works: It contains the metadata for a single connection (session:{sid} -> Gateway Node 42). It also tracks the device_id, when they connected, and the timestamp of their last heartbeat ping.
How They Work Together (The Routing Flow)
When the delivery worker needs to send a message to User B, it performs a two-step lookup using both of these records:
It queries Presence (presence:{UserB}) and gets back a list of active sessions (e.g., Session_Phone and Session_Laptop).
It queries the Session Registry for each of those IDs (session:{Session_Phone} and session:{Session_Laptop}) to find out exactly w