Senior

Návrh škálovatelného systému pro zasílání zpráv, který podporuje 150 milionů uživatelů, 75 milionů DAU, 225 milionů MAU, 1,2 milionu čtení / 300 tisíc zápisů QPS, 5 milionů současných uživatelů, 60 PB nových dat ročně, růst o 30 % ročně, P99 <200 ms pro čtení, <300 ms pro zápis, SLA 99,95 %. KONTEKST Je třeba navrhnout distribuovaný systém zasílání zpráv, podobný WhatsAppu, který podporuje 1:1 a skupinové chaty, zajišťuje doručení zpráv, zobrazuje online status uživatelů a přenáší multimediální soubory (fotky, videa, audia). Systém musí zajistit vysokou dostupnost a nízkou latenci, podporovat vysoký paralelismus a škálovat na globální úrovni. FUNKČNÍ POŽADAVKY - Podpora osobních (1:1) a skupinových chatů s možností přidávat/odstraňovat účastníky - Odesílání a přijímání textových zpráv a multimediálních souborů Nefunkční požadavky: - Neexistuje explicitní implementace end-to-end šifrování na úrovni služeb nebo klientů, kromě obecné poznámky. - Není jasně popsáno sharding a replikace databází podle chat_id nebo user_id pro škálovatelnost a odolnost vůči chybám. - Neexistuje žádná explicitní komponenta nebo mechanismus pro offline synchronizaci zpráv a potvrzení doručení. - Není jasné, jak je realizováno vyvažování zátěže mezi databázemi a službami, zejména při špičkových zatíženích. Důležité body k zvážení: (Diagram ukazuje architekturu s Load Balancerem, API Gateway, Message Queue, Service, Cache, Database, Object Storage a CDN)

sobes.tech AI

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

Předchozí Další