Senior

Mērogo ziņojumu sistēmas projektēšana, kas atbalsta 150 miljonus lietotāju, 75 miljonus DAU, 225 miljonus MAU, 1,2 miljonus lasījumu / 300 tūkstošus rakstu QPS, 5 miljonus vienlaicīgu lietotāju, 60 PB jaunu datu gadā, 30% gada pieaugumu, P99 <200 ms lasīšanai, <300 ms rakstīšanai, SLA 99,95%. KONTEKSTS Nepieciešams izstrādāt izplatītu ziņojumu sistēmu, līdzīgu WhatsApp, kas atbalsta 1:1 un grupu tērzēšanu, nodrošina ziņojumu piegādi, parāda lietotāju tiešsaistes statusus un pārsūta multimediju failus (attēlus, video, audio). Sistēma jānodrošina ar augstu pieejamību un zemu latentumu, jāatbalsta augsts paralēlisms un jāpaplašina globālā mērogā. FUNKCIONĀLIE PRASĪBAS - Atbalsts personīgiem (1:1) un grupu tērzēšanas ar iespēju pievienot/noņemt dalībniekus - Teksta ziņojumu un multimediju failu sūtīšana un saņemšana NEFUNKCIONĀLIE PRASĪBAS - Nav skaidras end-to-end šifrēšanas īstenošanas pakalpojumu vai klientu līmenī, izņemot vispārēju piezīmi. - Nav skaidri aprakstīts sharding un replikācija datu bāzēs pēc chat_id vai user_id, lai nodrošinātu mērogojamību un kļūdu tolerance. - Nav skaidrs komponentu vai mehānisma offline ziņojumu sinhronizācijai un piegādes apliecinājumiem. - Nav skaidrs, kā tiek veikta slodzes balansēšana starp datu bāzēm un pakalpojumiem, īpaši plūsmu laikā. Svarīgi aspekti, kas jāņem vērā: (Diagrama rāda arhitektūru ar Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage un CDN)

sobes.tech AI

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

Iepriekšējais Tālāk