Senior

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

Companies where asked

Яндекс

Answer from AI

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

Previous Next