Senior

Navrhnite škálovateľný systém na odosielanie správ, ktorý podporuje 150 miliónov používateľov, 75 miliónov DAU, 225 miliónov MAU, 1.2M čítaní / 300k zápisov QPS, 5 miliónov súčasných používateľov, 60 PB nových dát ročne, rast 30% ročne, P99 <200 ms pre čítanie, <300 ms pre zápis, SLA 99.95%. KONTEXT Je potrebné navrhnúť distribuovaný systém na odosielanie správ, podobný WhatsApp, ktorý podporuje 1:1 a skupinové chaty, zabezpečuje doručenie správ, zobrazuje online stavy používateľov a prenáša multimediálne súbory (fotky, videá, audio). Systém musí zabezpečiť vysokú dostupnosť a nízku latenciu, zvládať vysoký paralelizmus a byť škálovateľný na globálnej úrovni. FUNKČNÉ POŽIADAVKY - Podpora osobných (1:1) a skupinových chatov s možnosťou pridania/odstránenia účastníkov - Odosielanie a prijímanie textových správ a multimediálnych súborov Nefunkčné požiadavky: - Nie je jasná implementácia mechanizmu end-to-end šifrovania na úrovni služieb alebo klientov, okrem všeobecnej poznámky. - Chýba jasný opis sharding a replikácie databáz podľa chat_id alebo user_id pre škálovateľnosť a odolnosť voči chybám. - Nie je jasný žiadny komponent alebo mechanizmus pre offline synchronizáciu správ a potvrdení doručenia. - Nie je jasné, ako sa vykonáva vyvažovanie záťaže medzi databázami a službami, najmä pri špičkách. Kritické body na zváženie: (Diagrama ukazuje architektúru s Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage a CDN.)

sobes.tech AI

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

Predchádzajúce Ďalej