Systems Diagram
Do not spend time trying to make this pretty. It is just a tool to understand your thought process and have a shared understanding of the system so that we can discuss it verbally.
Requirements
Conversations
Conversation
User sees a list of conversations, with the most recently active conversations first.
Scrolling down shows additional conversations.
Tapping a conversation starts a new conversation.
User sees a list of messages sorted in order.
Scrolling up reveals additional messages.
Ask from candidate
- Clear and comprehensive API proposal that meets the product needs.
- Clear and comprehensive data model proposal that fits the API design, is scalable, and reliable.
- Clear data flow for both online and offline messaging.
Non-requirements (the following are NOT in scope for this problem)
- User authentication
- Group chat (1:1 only)
- Read receipts
- Typing indicators
- Contact online indicators
- Attachments
- Contact management. (You can pull contacts from the device or manually enter in a phone number.)
- Name entry. (We can assume that is pulled from the device.)
API Design
PATH: /v1/users
POST
REQ {}
RESP 200 OK {}
PUT
REQ {}
RESP 201 CREATED {}
PATH: /v1/messages
POST
REQ {}
RESP 200 OK {}
PUT
REQ {}
RESP 201 CREATED {}
Schemas
USERS Database Table
Field Name | Field Type | Example Value
id | int64 | 1234这是一道典型的 Meta 消息系统设计题，核心不是写复杂算法，而是把 1:1 聊天的产品需求拆成清晰的 API、数据模型和消息流。题目要求设计会话列表与消息列表的查询 / 分页方式，支持按最近活跃排序、向下加载更多会话、向上翻阅更多历史消息，并说明在线与离线发送消息时端到端的数据流。回答时通常要围绕 users、messages、conversation 等核心实体建模，考虑消息写入、读取、排序、游标分页以及服务端持久化与同步机制，同时明确不需要处理登录、已读回执、输入中状态、附件和群聊等范围外功能。
