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 | 1234This is a classic Meta messaging-system design question focused on APIs, data modeling, and message flow rather than algorithms. A strong solution should define endpoints for conversation and message retrieval, support recent-first conversation ordering, pagination in both directions, and explain how online and offline messaging are delivered and persisted. The key is to model core entities such as users, conversations, and messages, then describe reliable storage, ordering, and sync semantics while explicitly excluding out-of-scope features like authentication, read receipts, typing indicators, attachments, and group chat.
