Design de um sistema de mensagens escalável suportando 150 milhões de utilizadores, 75 milhões de DAU, 225 milhões de MAU, 1,2M de leituras / 300k de escritas no pico de QPS, 5 milhões de utilizadores simultâneos, 60 PB de novos dados por ano, crescimento de 30% ao ano, SLA de 99,95%, p99 <200 ms para leitura, <300 ms para escrita. 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 permita a transferência de ficheiros multimédia (fotos, vídeos, áudios). O sistema deve garantir alta disponibilidade e baixa latência, suportar alto paralelismo e escalar globalmente. REQUISITOS FUNCIONAIS - Suporte para chats pessoais (1:1) e em grupo com capacidade de adicionar/remover participantes - Envio e receção de mensagens de texto e ficheiros multimédia Não há uma implementação clara do 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. - Não há um componente ou mecanismo claro para lidar com sincronização offline de mensagens e recibos de entrega. - A forma como se realiza o balanceamento de carga entre bases de dados e serviços, especialmente em picos de carga, não está clara. **Pontos críticos a considerar:**

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

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

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

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