Senior

Designing a scalable messaging system supporting 150 million users, 75 million DAU, 225 million MAU, 1.2M read / 300k write QPS, 5 million concurrent users, 60 PB of new data annually, 30% growth per year, P99 <200 ms for read, <300 ms for write, SLA 99.95%. CONTEXT You need to design a distributed messaging system similar to WhatsApp, supporting both 1:1 and group chats, ensuring message delivery, displaying user online statuses, and transmitting multimedia files (photos, videos, audio). The system must ensure high availability and low latency, handle high concurrency, and scale globally. FUNCTIONAL REQUIREMENTS - Support for personal (1:1) and group chats with the ability to add/remove participants - Sending and receiving text messages and multimedia files NON-FUNCTIONAL REQUIREMENTS: - No explicit implementation of end-to-end encryption at the service or client level, except for a general annotation. - No explicit description of sharding and database replication by chat_id or user_id for scalability and fault tolerance. - No explicit component or mechanism for offline message synchronization and delivery receipts. - It is not clear how load balancing is implemented between databases and services, especially during peak loads. Bottlenecks to pay attention to: (The architecture diagram shows Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage, and CDN)

sobes.tech AI

Answer from AI

To design a scalable messenger with such requirements, several key aspects need to be considered:

1. Architecture and scalability:

Use microservices architecture with separation by functionality (chats, messages, users, multimedia).
Horizontal scaling of services and databases.
Data sharding by user_id or chat_id to distribute load.

2. Data storage:

Messages and metadata — in a distributed NoSQL database (e.g., Cassandra, ScyllaDB) for high write and read performance.
Multimedia — in object storage (S3-like) with CDN for fast delivery.

3. Message processing:

Use message queues (Kafka, RabbitMQ) for asynchronous processing and delivery.
Guaranteed delivery with acknowledgments (delivery receipts).

4. Online statuses and presence:

Store statuses in a fast in-memory store (Redis).
Publish changes via WebSocket or push services.

5. Load balancing and fault tolerance:

Load balancer and API Gateway for request distribution.
Database replication and automatic failover.

6. Performance and SLA:

Caching hot data.
Monitoring and alerting for quick response.

7. Security:

General note on end-to-end encryption, but without implementation.

Example simplified schema:

[Clients] -> [Load Balancer] -> [API Gateway] -> [Microservices]
                                   |
                                   -> [Message Queue] -> [Database]
                                   -> [Cache (Redis)]
                                   -> [Object Storage + CDN]

Important bottlenecks:

Implementation of offline synchronization and delivery receipts.
Load balancing during peak loads.
Sharding and replication for scalability and fault tolerance.

To achieve P99 <200 ms read and <300 ms write, data paths need to be optimized, caching used, and asynchronous message processing employed.

Previous Next