Senior

Projetar um sistema de mensagens escalável com suporte para 150 milhões de utilizadores, 75 milhões de DAU, 225 milhões de MAU, 1.2M leituras / 300k escritas QPS, 5 milhões de utilizadores simultâneos, 60 PB de novos dados por ano, crescimento de 30% ao ano, P99 <200 ms para leitura, <300 ms para escrita, SLA 99.95%. CONTEXT É necessário projetar um sistema de mensagens distribuído, semelhante ao WhatsApp, que suporte chats 1:1 e em grupo, garanta a entrega de mensagens, exiba estados online dos utilizadores e transmita ficheiros multimédia (fotos, vídeos, áudio). O sistema deve garantir alta disponibilidade e baixa latência, suportar alto paralelismo e escalar globalmente. REQUISITOS FUNCIONAIS - Suporte a chats pessoais (1:1) e em grupo com possibilidade de adicionar/remover participantes - Envio e receção de mensagens de texto e ficheiros multimédia Requisitos não funcionais: - Sem implementação explícita de mecanismo de encriptação end-to-end ao nível de serviços ou clientes, além de uma anotação geral. - Ausência de descrição explícita de sharding e replicação de bases de dados por chat_id ou user_id para escalabilidade e tolerância a falhas. - Sem componente ou mecanismo explícito para processamento de sincronização offline de mensagens e recibos de entrega. - Não está claro como é feita a balanceamento de carga entre bases de dados e serviços, especialmente em picos de carga. Pontos críticos a serem considerados: (A arquitetura mostrada na diagrama inclui Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage e CDN)

sobes.tech IA

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

Anterior Próximo