Senior

Conception d'un système de messagerie évolutif supportant 150 millions d'utilisateurs, 75 millions de DAU, 225 millions de MAU, 1,2 million de lectures / 300k d'écritures par seconde, 5 millions d'utilisateurs simultanés, 60 PB de nouvelles données par an, croissance de 30% par an, P99 <200 ms pour la lecture, <300 ms pour l'écriture, SLA 99,95%. CONTEXTE Il est nécessaire de concevoir un système de messagerie distribué, similaire à WhatsApp, qui supporte les chats 1:1 et de groupe, assure la livraison des messages, affiche les statuts en ligne des utilisateurs et transmet des fichiers multimédias (photos, vidéos, audios). Le système doit assurer une haute disponibilité et une faible latence, supporter un haut parallélisme et évoluer à l'échelle mondiale. EXIGENCES FONCTIONNELLES - Support pour les chats personnels (1:1) et de groupe avec possibilité d'ajouter/supprimer des participants - Envoi et réception de messages texte et de fichiers multimédias Exigences non fonctionnelles: - Aucune implémentation explicite de chiffrement de bout en bout au niveau des services ou des clients, sauf une annotation générale. - Absence de description claire du sharding et de la réplication des bases de données par chat_id ou user_id pour la scalabilité et la tolérance aux pannes. - Aucun composant ou mécanisme explicite pour gérer la synchronisation hors ligne des messages et des accusés de réception. - La répartition de la charge entre les bases de données et les services, notamment lors des pics de charge, n'est pas détaillée. Points critiques à considérer: (Le diagramme montre une architecture avec Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage et CDN)

sobes.tech IA

Réponse de l'IA

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

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 мс записи необходимо оптимизировать пути данных, использовать кэширование и асинхронную обработку сообщений.

Précédent Suivant