Conception d'un système de messagerie évolutif supportant 150 millions d'utilisateurs, 75 millions de DAU, 225 millions de MAU, 1,2M de lectures / 300k d'écritures en pic de QPS, 5 millions d'utilisateurs simultanés, 60 PB de nouvelles données par an, croissance de 30% par an, SLA de 99,95%, p99 <200 ms pour la lecture, <300 ms pour l'écriture. CONTEXTE Il faut concevoir un système de messagerie distribué, similaire à WhatsApp, supportant les chats 1:1 et de groupe, assurant la livraison des messages, l'affichage des statuts en ligne des utilisateurs et le transfert de fichiers multimédia (photos, vidéos, audios). Le système doit garantir une haute disponibilité et une faible latence, supporter un haut parallélisme et évoluer à l'échelle mondiale. EXIGENCES FONCTIONNELLES - Support des 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édia Aucun mécanisme clair de chiffrement end-to-end n'est visible au niveau des services ou des clients, à l'exception d'une annotation générale. - Absence de description explicite 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 clair pour gérer la synchronisation hors ligne des messages et des accusés de réception. - La répartition de la charge entre bases de données et services, notamment en période de pics, n'est pas claire. **Points critiques à considérer :**

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

1. Шардинг и репликация данных

   • Разделение данных по user_id или chat_id для распределения нагрузки между базами.
   • Репликация для обеспечения отказоустойчивости и быстрого чтения.

2. Обработка офлайн-синхронизации и delivery receipts

   • Хранение сообщений на сервере до подтверждения доставки.
   • Механизмы push-уведомлений и синхронизации при повторном подключении.

3. Балансировка нагрузки

   • Использование балансировщиков на уровне API и сервисов.
   • Горизонтальное масштабирование микросервисов.

4. Обеспечение SLA и низкой задержки

   • Кэширование часто запрашиваемых данных (например, online-статусов).
   • Использование быстрых хранилищ (in-memory, NoSQL) для сообщений и статусов.

5. Мультимедийные файлы

   • Отдельное хранилище (CDN, Object Storage) для медиа.
   • Асинхронная загрузка и доставка.

6. Безопасность

   • End-to-end шифрование желательно реализовать на клиенте.
   • Сервер отвечает за маршрутизацию и хранение зашифрованных данных.

7. Архитектура сервисов

   • Микросервисный подход: отдельные сервисы для сообщений, пользователей, мультимедиа, уведомлений.
   • Очереди сообщений (Kafka, RabbitMQ) для обработки пиковых нагрузок.

8. Мониторинг и алертинг

   • Метрики производительности, задержек, ошибок.
   • Автоматическое масштабирование при росте нагрузки.

В итоге, архитектура должна быть распределённой, с чётким разделением ответственности, поддержкой горизонтального масштабирования и высокой доступности. Особое внимание стоит уделить механизмам доставки сообщений, синхронизации офлайн-пользователей и эффективному хранению больших объёмов данных.