Senior

Proiectați o aplicație de mesagerie scalabilă, suportând 150 milioane de utilizatori, cu 75 milioane DAU, 225 milioane MAU, 1.2M citiri / 300k scrieri QPS, 5 milioane de utilizatori simultani, 60 PB de date noi pe an, creștere de 30% pe an, P99 <200 ms pentru citire, <300 ms pentru scriere, SLA 99.95%. CONTEXT Este necesar să proiectați un sistem de mesagerie distribuit, similar cu WhatsApp, care suportă chat-uri 1:1 și de grup, asigură livrarea mesajelor, afișează statusurile online ale utilizatorilor și transmite fișiere multimedia (poze, video, audio). Sistemul trebuie să asigure disponibilitate ridicată și latență scăzută, să suporte paralelism ridicat și să fie scalabil la nivel global. CERINȚE FUNCȚIONALE - Suport pentru chat-uri personale (1:1) și de grup cu posibilitatea de a adăuga/remova participanți - Trimiterea și primirea de mesaje text și fișiere multimedia Cerinte non-funcționale: - Fără implementare explicită a mecanismului de criptare end-to-end la nivel de servicii sau clienți, în afară de o notare generală. - Fără descriere explicită a sharding-ului și replicării bazelor de date pe chat_id sau user_id pentru scalabilitate și toleranță la defecte. - Fără componentă sau mecanism explicit pentru sincronizarea offline a mesajelor și confirmărilor de livrare. - Nu este clar cum se face echilibrarea încărcăturii între baze de date și servicii, mai ales în perioadele de vârf. Puncte critice de luat în considerare: (Diagrama arată o arhitectură cu Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage și CDN)

sobes.tech AI

Răspuns de la AI

Для проектирования масштабируемого мессенджера с такими требованиями нужно учесть несколько ключевых аспектов:

1. Архитектура и масштабируемость:

Использовать микросервисную архитектуру с разделением по функционалу (чаты, сообщения, пользователи, мультимедиа).
Горизонтальное масштабирование сервисов и баз данных.
Шардинг данных по user_id или chat_id для распределения нагрузки.

2. Хранение данных:

Сообщения и метаданные — в распределённой NoSQL базе (например, Cassandra, ScyllaDB) для высокой записи и чтения.
Мультимедиа — в объектном хранилище (S3-подобном) с CDN для быстрой доставки.

3. Обработка сообщений:

Использование очередей сообщений (Kafka, RabbitMQ) для асинхронной обработки и доставки.
Гарантированная доставка с подтверждениями (delivery receipts).

4. Онлайн-статусы и presence:

Хранение статусов в быстром in-memory хранилище (Redis).
Публикация изменений через WebSocket или push-сервисы.

5. Балансировка нагрузки и отказоустойчивость:

Load balancer и API Gateway для распределения запросов.
Репликация баз данных и автоматическое переключение при сбоях.

6. Производительность и SLA:

Кэширование горячих данных.
Мониторинг и алертинг для быстрого реагирования.

7. Безопасность:

Общая аннотация про end-to-end шифрование, но без реализации.

Пример упрощённой схемы:

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

Важные узкие места:

Реализация офлайн-синхронизации и delivery receipts.
Балансировка нагрузки при пиковых нагрузках.
Шардинг и репликация для масштабируемости и отказоустойчивости.

Для достижения P99 <200 мс чтения и <300 мс записи необходимо оптимизировать пути данных, использовать кэширование и асинхронную обработку сообщений.

Anterior În continuare