System requirements

Functional:

• User Management:
• Users can register, login, and update profiles.
• Users can search for other users by name, username, or email.
• Users can add friends and manage their friend lists.
• Messaging:
• Users can send and receive one-on-one text messages, voice messages, and video calls.
• Users can create group chats with multiple participants.
• Messages can include attachments like images, videos, and documents.
• Users can see message delivery status (sent, delivered, read).
• Features:
• Users can create and join chat rooms for public discussions.
• Users can react to messages with emojis or stickers.
• Users can mute notifications for individual chats or temporarily disable notifications altogether.
• The platform should integrate with Facebook to leverage existing friend connections.

Non-Functional:

• Scalability: The system should handle a large number of concurrent users and message volume.
• Availability: The system should be highly available with minimal downtime.
• Performance: Messages should be delivered with low latency and users should experience fast response times.
• Security: User data and communication should be encrypted. The system should be resistant to hacking attempts.
• Reliability: The system should recover gracefully from failures and ensure data integrity.

Capacity estimation

Estimating the precise user base and message volume is challenging without real data. However, we can make educated guesses based on existing messaging services. Here are some assumptions:

• Active Users: 100 million daily active users (DAUs)
• Average Messages per User per Day: 50 messages/day/user
• Average Message Size: 1 KB (text-based message)
• Percentage of Messages with Attachments: 10%

This translates to:

• Daily Messages: 5 billion messages/day
• Daily Data Ingestion: 5.5 GB/day (including attachments)

These are estimates, and the actual numbers could be higher or lower. The system needs to be designed to scale to accommodate future growth and unexpected spikes in activity.

API design

The system will expose APIs for various functionalities:

• User Management: APIs for user registration, login, profile management, and searching for users.
• Messaging: APIs for sending and receiving messages, managing message status, and handling attachments.
• Chat Management: APIs for creating and managing one-on-one and group chats, including adding/removing participants.
• Features: APIs for sending reactions, muting notifications, and integrating with Facebook.

Additionally, APIs for internal communication within the system might be needed, such as notifications for new messages and presence information (online/offline status).

Database design

The system utilizes a relational database for core user data and message information. Here's a simplified Entity-Relationship (ER) Diagram:

• User: Stores user information like username, email, profile picture, etc.
• Message: Stores message content, timestamp, sender (foreign key to User), recipient(s) (foreign key to User for one-on-one chats, or Chat for group chats), and message type (text, voice, video).
• Media: Stores information about uploaded media associated with messages (optional, foreign key to Message).
• Chat: Stores information about group chats, including the name, creation time, and list of participants (foreign key to User).
• Friends: Links users who are friends (many-to-many relationship between User and User).
• InChat: Links users to the chats they participate in (many-to-many relationship between User and Chat).

Class Diagram

High-level design

The system can be divided into several components:

• User Interface (UI): Web and mobile apps for user interaction (sending/receiving messages, managing contacts, etc.).
• API Gateway: Receives user requests and routes them to appropriate services.
• User Service: Handles user management functionalities (registration, login, profile management, etc.).
• Messaging Service: Handles message exchange (sending, receiving, delivery status), including attachments.
• Chat Service: Manages chat creation, management (adding/removing participants), and group chat information.
• Notification Service: Sends notifications to users about new messages, mentions, etc.
• Search Service: Enables searching

Request flows

Here's an example flow for sending a text message:

1. User initiates action: The user performs an action through the UI, such as composing a text message and selecting a recipient.
2. UI sends request: The UI sends a request to the API Gateway. This request typically includes relevant data like user credentials, message content, and recipient information.
3. API Gateway routes request: The API Gateway acts as a central entry point, routing the request to the appropriate service based on the functionality requested.
4. Service handles request: The specific service responsible for the functionality (e.g., Messaging Service) receives the request and processes it.
5. Service interaction (optional): Depending on the request, the service might interact with other services for additional functionalities.

• For example, sending a message with an attachment might involve interacting with a Media Service to store the attachment.
• Sending a message to an online user might involve triggering a Notification Service to send a push notification.

1. Service updates database: The service updates the database with relevant information based on the request. This could involve storing messages, updating user profiles, or creating new chat entries.
2. Service sends response: The service sends a response back to the API Gateway indicating success or failure (with an error message if applicable).
3. API Gateway returns response: The API Gateway relays the service's response back to the UI.
4. UI updates: The UI receives the response and updates itself accordingly. In case of a successful message send, the UI might display a confirmation message or update the chat window.

Similar request flows exist for other functionalities like:

• Creating a group chat: User initiates creation, UI sends request, Chat Service creates the chat in the database, and UI updates to reflect the new chat.
• Following a user: User follows another user, UI sends request, User Service updates the following relationship in the database, and UI reflects the change.
• Searching for messages/users: User enters search terms, UI sends request, Search Service retrieves results from the database, and UI displays the search results.

Detailed component design

1. Messaging Service:

• Responsibilities:
• Process incoming message requests (send, receive, delivery status).
• Store messages and attachments in the database.
• Manage message delivery logic (push notifications for online users, queuing for offline users).
• Scalability:
• The service can scale horizontally by adding more instances to handle increased message volume.
• Message queues can be implemented to buffer messages during peak loads.
• Data Structures:
• In-memory queues can be used to store messages waiting for delivery (especially for online users).

2. User Service:

• Responsibilities:
• Handle user registration, login, authentication, and profile management.
• Maintain user information and online/offline status.
• Scalability:
• The service can scale horizontally by adding more instances for user authentication and profile management.
• Caching mechanisms can be used to store frequently accessed user data (e.g., online status) for faster retrieval.
• Algorithms:
• Secure hashing algorithms can be used to store user passwords in a secure manner.

Trade offs/Tech choices

• Database Choice:
• Relational database for core user data and message information offers strong consistency and schema enforcement.
• NoSQL database might be explored for storing attachments or message history if scalability becomes a major concern.
• Push Notifications:
• Implementing push notifications for real-time updates increases user engagement but adds complexity and relies on external services.
• Polling for new messages can be an alternative, but it might lead to delays in message delivery.

Failure scenarios/bottlenecks

• API Gateway Failure:
• Implement redundancy with multiple API Gateway instances for failover.
• Database Outage:
• Use database replication with automatic failover to a secondary database.
• Messaging Service Overload:
• Implement horizontal scaling and message queuing for handling peak loads.
• Network Issues:
• Design the system to handle temporary network disruptions and retry message delivery attempts.

Future improvements

• Real-time chat: Explore WebSockets or Server-Sent Events for low-latency, real-time chat experiences.
• End-to-End Encryption: Implement end-to-end encryption for messages to enhance user privacy.
• Advanced Search: Include features like searching within chats, filtering by message type (text, attachments), and searching for specific keywords within messages.
• Offline Messaging: Allow users to send messages even when the recipient is offline, with queuing and delivery upon reconnection.