Senior

Diseño de un sistema de mensajería escalable que soporte 150 millones de usuarios, 75 millones de DAU, 225 millones de MAU, 1.2M de lecturas / 300k de escrituras por segundo, 5 millones de usuarios simultáneos, 60 PB de datos nuevos al año, crecimiento del 30% anual, P99 <200 ms para lectura, <300 ms para escritura, SLA 99.95%. CONTEXTO Se requiere diseñar un sistema distribuido de mensajería, similar a WhatsApp, que soporte chats 1:1 y grupales, garantice la entrega de mensajes, muestre estados en línea de los usuarios y transmita archivos multimedia (fotos, videos, audios). El sistema debe garantizar alta disponibilidad y baja latencia, soportar alto paralelismo y escalar a nivel global. REQUISITOS FUNCIONALES - Soporte para chats personales (1:1) y grupales con capacidad para añadir/eliminar participantes - Envío y recepción de mensajes de texto y archivos multimedia Requisitos no funcionales: - No hay implementación explícita de cifrado de extremo a extremo a nivel de servicios o clientes, aparte de una anotación general. - No se describe claramente el sharding y la replicación de bases de datos por chat_id o user_id para escalabilidad y tolerancia a fallos. - No hay un componente o mecanismo explícito para manejar la sincronización offline de mensajes y recibos de entrega. - No se detalla cómo se realiza el balanceo de carga entre bases de datos y servicios, especialmente en picos de carga. Puntos críticos a tener en cuenta: (En el diagrama se muestra una arquitectura con Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage y CDN)

sobes.tech AI

Respuesta de la 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 Siguiente