Here is some concepts about system design of chat app.

1. Design

Link: https://blog.algomaster.io/p/97768905-4e7d-4e72-adfa-af6e79d75101

Overall System

Check Connection Status

Send Message

WebSockets enable real-time status updates for messages (e.g., “message sent,” “message delivered,” “message read”), providing users with instant feedback on message states.

Message Sent

When User A sends a message, it is transmitted over their WebSocket connection to the server handling their connection (Server A).

• Server A receives the message, pushes it to the message queue for storage, and sends an acknowledgment back to User A.

• Upon receiving this acknowledgment, User A’s app updates the message status to “sent.”

If User A is offline when attempting to send a message, the message won’t be sent until they are back online. The message remains in a pending state on User A’s device until it reconnects and successfully sends the message to Server A.

Message Delivered

Once the User B receives the message, it sends an acknowledgment to Server B.

• Server B sends a delivery acknowledgment to Server A.

• Server A sends the message status “delivered” to the message queue for permanent storage and then relays this update to User A’s app, which reflects the message as “delivered.”

• If User B is offline, Server A will not receive an acknowledgment of delivery from Server B, so the message remains in the “sent” state for User A until User B reconnects.

When User B comes online, the client app sends the updates to Server B, at which point it sends a “delivered” acknowledgment to Server A. User A’s app is then updated to reflect the “delivered” status.

Message Read

When User B opens the chat window and views the message, their app sends a “read” acknowledgment to Server B.

• Server B logs this event in the message queue and forwards the “read” status to Server A.

• Server A pushes this update to User A’s device, allowing User A’s app to display the message as “read.”

• If User B is offline, they cannot view the message, so it will not trigger a “read” status. When User B reconnects and opens the chat, their app will send a “read” acknowledgment to Server B.

• The Server B logs the “read” status in the message queue and forwards it to Server A. User A’s app then receives this update, marking the message as “read.”

Group Chat

2. Notes

2.1. Sharding

To support horizontal scaling and efficient data access, we can implement sharding across different data types:

• User Data Sharding: Shard user data based on user_id. This will allow us to distribute user records across multiple servers and enable us to scale as the user base grows.

• Message Data Partitioning: Partition messages based on message_id, using a timestamp-based message_id to enable efficient time-based searches. This structure allows recent messages to be accessed quickly and older messages to be located based on timestamp.

2.2 Optimizing Storage Cost

With large volumes of messages and multimedia content, optimizing storage costs is essential.

Here are some effective strategies:

• Compress Multimedia Files: Compressing large files (e.g., images, videos) can reduce storage requirements and cuts costs significantly.

• Archive Older Messages: Most users only access recent messages, which can be cached locally on their devices. Older messages can be moved to lower-cost, cold storage (e.g., Amazon Glacier), reducing expenses while still allowing access if needed.

• Deduplicate Files: Avoid storing multiple copies of identical files by implementing deduplication, which can save significant space when the same media is shared across multiple users or groups.

• Efficient Metadata Storage: Store metadata (e.g., file type, size, timestamps) separately from the media itself to reduce the load on primary storage and make searches faster and more efficient.