Проектирование масштабируемого мессенджера с поддержкой 150 млн пользователей, 75 млн DAU, 225 млн MAU, 1.2M read / 300k write peak QPS, 5 млн одновременных пользователей, 60 PB новых данных в год, рост 30% в год, SLA 99.95%, p99 <200 мс для чтения, <300 мс для записи. КОНТЕКСТ Необходимо спроектировать распределённую систему мессенджера, аналогичную WhatsApp, которая поддерживает как 1:1, так и групповые чаты, обеспечивает доставку сообщений, отображение online-статусов пользователей и передачу мультимедийных файлов (фото, видео, аудио). Система должна обеспечивать высокую доступность и низкую задержку, выдерживать высокий параллелизм и масштабироваться на глобальном уровне. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ - Поддержка личных (1:1) и групповых чатов с возможностью добавления/удаления участников - Отправка и получение текстовых сообщений и мультимедийных файлов НЕ ВИДНО ЯВНОЙ РЕАЛИЗАЦИИ МЕХАНИЗМА end-to-end шифрования на уровне сервисов или клиентов, кроме общей аннотации. - Отсутствует явное описание шардингов и репликаций баз данных по chat_id или user_id для масштабируемости и отказоустойчивости. - Нет явного компонента или механизма для обработки офлайн-синхронизации сообщений и delivery receipts. - Не прослеживается, как реализуется балансировка нагрузки между базами данных и сервисами, особенно при пиковых нагрузках. **Узкие места, на которые стоит обратить внимание:**

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

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. Мониторинг и алертинг

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

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