Designing a Scalable Group Chat System: Architecture, Components, and High‑Concurrency Strategies

1. Introduction

The author reflects on a real‑world WeChat group used for a company outing and uses the scenario as a springboard to discuss how to design a group chat system that could serve up to 1 billion users.

2. System Requirements

2.1 Functional Requirements

Create Group : Users can create a new chat group and invite friends or strangers.

Group Management : Owners and admins can manage members, set rules and permissions.

Message Send/Receive : Support text, image, audio, video messages and broadcast to all members.

Real‑time Communication : Messages must be delivered with low latency.

Red Packet : Users can send random‑amount red packets that other members can claim.

2.2 Non‑functional Requirements

High Concurrency : The system must handle massive simultaneous group creation and usage without latency.

High Performance : Fast message delivery and instant response are critical for a social app.

Massive Storage : Scalable storage for huge volumes of text, images, audio, and video data.

3. Core Components

3.1 Core Components

The architecture consists of the following modules:

Client : Receives group chat messages on mobile or PC and forwards them to the backend.

WebSocket Transport Protocol : Low‑overhead, high‑realtime bidirectional communication.

Long‑Connection Cluster : Maintains WebSocket connections and forwards messages via middleware.

Message Processing Server Cluster : Handles real‑time message processing, storage, and database interaction.

Message Push Server Cluster : Routes messages to the correct group members.

Database Server Cluster : Stores user text data, image thumbnails, and audio/video metadata.

Distributed File Storage Cluster : Persists user‑uploaded images, audio, and video files.

4. Face‑to‑Face Group Creation

Users generate a 4‑digit random code; anyone nearby who enters the same code joins the same group. The data model includes four tables:

User : Stores user ID, nickname, avatar, etc.

Group : Stores group ID, name, creator ID, member count.

GroupMember : Associates users with groups.

RandomCode : Stores the random code and its linked group ID.

4.2 Core Business Flow

When a user initiates a face‑to‑face group, the system caches HashMap {random code → user list} with an expiration of 3min. The flow proceeds as follows: {随机码，用户列表[用户A(ID、名称、头像)]} User A creates the group, the random code is saved in RandomCode and linked to a new group ID. When User B enters the same code, the backend checks the cache; if the code exists, the user is added to GroupMember after verifying the group has not exceeded the maximum of 500 members.

If multiple users join simultaneously, two solutions are discussed:

Wrap the Group member count read and GroupMember insert in a MySQL transaction (risking table locks and lower performance).

Use Redis atomic incr on a key representing the group ID; if the count exceeds the limit, decrement and return a “group full” response. This leverages Redis’s atomicity and is similar to anti‑oversell strategies in e‑commerce.

Location filtering (e.g., within 50 m) can be implemented with Redis GeoHash to retrieve users in the area.

5. Message Send and Receive

When a member sends a message (text, image, video, or audio), the client uploads media to the backend, which stores metadata in MySQL and the actual files in the distributed file storage cluster. The backend writes a record to the Message table (including MediaID) and broadcasts the message to all group members.

5.1 Interaction Flow

User A sends a message with media.

The client uploads the media to the server.

The server stores the message in Message and the media in the file storage cluster, recording MediaID in the message.

The server pushes the message to all group members; clients render it according to its type.

When a user clicks a thumbnail, the client uses MediaID to fetch the file from the object storage cluster.

5.2 Message Storage and Display

Additional tables support the messaging feature:

Message : Stores each message’s ID, type, content, sender ID, group ID, timestamp, etc.

Media : Stores uploaded media files with a unique MediaID, file path, uploader ID, and timestamps.

MessageState : Records per‑user read status; used to compute unread counts for push notifications.

The unread‑count design stores the count in MessageState. Clients query an API that aggregates per‑group unread numbers. To improve performance, the count is cached in Redis; when the count exceeds 99, it is capped at “100+” (represented by 99+) to reduce storage and network overhead.

When fetching unread counts with select count, a full table scan occurs, so caching in Redis avoids the slowdown.

6. High‑Performance & High‑Availability Design

Cluster Deployment : All services (long‑connection, push, database, file storage) run in scalable clusters to prevent single‑node failures and enable elastic scaling.

Message Queue : Kafka (or similar) buffers messages for asynchronous consumption, smoothing traffic spikes.

Multithreading : Parallel processing of message writes and consumption reduces hardware costs and increases throughput.

Caching Recent Messages : Recent chat history is cached to avoid repeated DB reads.

Time‑Based Scaling : Peak traffic periods trigger automatic node scaling to balance cost and performance.

7. Conclusion

Group chat is a core capability of social applications such as WeChat, QQ, Douyin, and Xiaohongshu. The design presented covers only a fraction of the challenges; features like red‑packet distribution and in‑group audio/video calls introduce additional technical complexities that further illustrate the richness of large‑scale system architecture.