Designing a Scalable 1B‑User Group Chat System: Architecture & High‑Concurrency

1. System Requirements

The interview scenario asks how to design a group‑chat system that can serve up to 1 billion daily active users. Functional needs include creating groups, managing members, sending various media types, real‑time communication, and the iconic "red‑packet" feature. Non‑functional requirements emphasize high concurrency, low latency, and massive storage for text, images, audio, and video.

2. Core Components

Client : Mobile or PC app that receives and sends chat messages.

WebSocket Transport : Low‑overhead, bi‑directional protocol for real‑time interaction.

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

Message Processing Cluster : Handles message persistence, querying, and database interaction.

Message Push Cluster : Routes processed messages to the appropriate group members.

Database Cluster : Stores user profiles, group metadata, and message records.

Distributed File Storage Cluster : Persists large media files (images, audio, video).

3. Database Schema for Face‑to‑Face Group Creation

User : id, nickname, avatar, …

Group : id, name, creator_id, member_count, …

GroupMember : user_id, group_id

RandomCode : code, group_id, expiration

When a user initiates a face‑to‑face group, the system generates a 4‑digit random code. Nearby users (within ~50 m) entering the same code are added to the same group. The code‑to‑user mapping is cached as

{随机码，用户列表[用户A(ID、名称、头像)]}

with a 3‑minute TTL.

4. Message Sending & Receiving

Messages (text, image, video, audio) are uploaded by the client, stored in a Message table (metadata) and a Media table (actual files). The flow is:

User sends a message with optional media.

Client uploads media to the object‑storage cluster.

Backend stores metadata in Message and Media tables.

Message is broadcast via the push cluster to all group members.

Clients render the content based on its type.

Unread counts are tracked in a MessageState table; for scalability the count is also cached in Redis, capping at 100 to avoid excessive updates.

5. Concurrency Control for Group Membership

Two approaches prevent exceeding the maximum group size (e.g., 500 members):

Wrap the read‑modify‑write sequence in a MySQL transaction (risking lock contention).

Use Redis INCR on a key representing the group’s member count; if the increment would exceed the limit, decrement and reject the join.

Redis’s atomic operations also support location‑based features via GeoHash, enabling the 50‑meter proximity check for face‑to‑face groups.

6. High‑Performance & High‑Availability Strategies

Cluster Deployment : All services (WebSocket servers, push servers, databases, storage) run in horizontally scalable clusters to avoid single points of failure.

Message Queues (e.g., Kafka): Decouple message production from consumption, providing asynchronous processing and traffic shaping.

Multithreading : Parallelize I/O‑bound tasks such as message ingestion and delivery.

Caching : Cache recent messages and group metadata to reduce database load; cache member counts for quick unread calculations.

Dynamic Scaling : Monitor traffic peaks and auto‑scale node counts accordingly.

Conclusion

The presented design outlines the essential architecture for a massive, real‑time group chat system, highlighting component choices, data models, concurrency safeguards, and performance optimizations that together enable scalability to billions of users.