Senior

Masteliojančios žinučių siuntimo sistemos projektavimas, kuri palaiko 150 milijonų naudotojų, 75 milijonų DAU, 225 milijonų MAU, 1,2 milijono skaitymų / 300 tūkst. rašymų QPS, 5 milijonus vienu metu veikiančių naudotojų, 60 PB naujų duomenų per metus, 30% metinis augimas, P99 <200 ms skaitymui, <300 ms rašymui, SLA 99,95%. KONTEKSTAS Reikia sukurti paskirstytą žinučių siuntimo sistemą, panašią į WhatsApp, kuri palaiko 1:1 ir grupinius pokalbius, užtikrina žinučių pristatymą, rodo naudotojų būsenas internete ir perduoda multimedijos failus (nuotraukas, vaizdo įrašus, garsus). Sistema turi užtikrinti aukštą prieinamumą ir žemą delsą, palaikyti didelį paralelizmą ir būti skalaujama pasauliniu lygiu. FUNKCINIAI REIKALAVIMAI - Palaikymas asmeninių (1:1) ir grupinių pokalbių su galimybe pridėti/pašalinti dalyvius - Tekstinių žinučių ir multimedijos failų siuntimas ir gavimas NEFUNKCINIAI REIKALAVIMAI - Nėra aiškios end-to-end šifravimo įgyvendinimo paslaugų ar klientų lygyje, išskyrus bendrą pastabą. - Aiškus duomenų bazės sharding ir replikacijos aprašymas pagal chat_id ar user_id nėra pateiktas, siekiant užtikrinti skalavimą ir atsparumą gedimams. - Nėra aiškios komponento ar mechanizmo offline žinučių sinchronizacijai ir pristatymo patvirtinimams. - Neaišku, kaip vyksta apkrovos paskirstymas tarp duomenų bazių ir paslaugų, ypač piko metu. Svarbūs aspektai, kuriuos reikia apsvarstyti: (Diagrama rodo architektūrą su Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage ir CDN)

sobes.tech AI

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

Ankstesnis Kitas