Design a One-to-One Chat Service

Design a messaging service for private conversations between two users. Cover message sending, retrieval, ordering, online and offline delivery, read state, retries, and failure recovery. Explain what guarantees the service provides when clients reconnect or submit the same request more than once.

Constraints & Assumptions

• A conversation has exactly two participants.
• Text messages are retained; large media storage is outside the core path.
• Users may have several devices and may be offline for long periods.
• Global ordering across unrelated conversations is unnecessary.
• The service must prevent nonparticipants from reading a conversation.

Clarifying Questions to Ask

• Is strict ordering required within a conversation or only per sender?
• Must delivery receipts and read receipts be supported?
• What retention and deletion rules apply?
• What peak send rate and reconnect fan-out should be expected?

Part 1 - API and data model

Define conversation, message, participant, cursor, and receipt records plus send and history APIs.

What This Part Should Cover

• Client-generated idempotency keys
• Conversation-scoped ordering IDs
• Authorization at read and write boundaries
• Cursor-based history retrieval

Part 2 - Delivery and consistency

Explain the durable write path, live delivery path, offline recovery, multi-device synchronization, and duplicate handling.

What This Part Should Cover

• Persist before acknowledging accepted messages
• At-least-once delivery with client deduplication
• Per-conversation order and reconnect cursors
• Receipt semantics separated from message durability

Part 3 - Scale and failures

Discuss partitioning, hot conversations, WebSocket gateways, backpressure, regional failure, and observability.

What This Part Should Cover

• Stable partition key and bounded fan-out
• Stateless gateways with resumable sessions
• Queue lag and slow-client protection
• Reconciliation after partial failure