Senior

Dizajn skalabilnog sistema za razmenu poruka koji podržava 150 miliona korisnika, 75 miliona DAU, 225 miliona MAU, 1.2 miliona čitanja / 300k pisanja QPS, 5 miliona istovremenih korisnika, 60 PB novih podataka godišnje, rast od 30% godišnje, P99 <200 ms za čitanje, <300 ms za pisanje, SLA 99,95%. KONTEKST Potrebno je dizajnirati distribuirani sistem za razmenu poruka, sličan WhatsApp-u, koji podržava 1:1 i grupne chatove, obezbeđuje dostavu poruka, prikazuje online statuse korisnika i prenosi multimedijalne fajlove (fotografije, video, audio). Sistem mora obezbediti visoku dostupnost i nisku latenciju, podržavati visok paralelizam i skalirati na globalnom nivou. FUNKCIONALNI ZAHTEVI - Podrška za lične (1:1) i grupne chatove sa mogućnošću dodavanja/uklanjanja učesnika - Slanje i primanje tekstualnih poruka i multimedijalnih fajlova Nefunkcionalni zahtevi: - Nema eksplicitne implementacije end-to-end enkripcije na nivou servisa ili klijenata, osim opšte napomene. - Nema jasnog opisa sharding-a i replikacije baza podataka po chat_id ili user_id radi skalabilnosti i otpornosti na greške. - Nema eksplicitnog komponenta ili mehanizma za offline sinhronizaciju poruka i potvrda isporuke. - Nije jasno kako se vrši balansiranje opterećenja između baza podataka i servisa, posebno pri vršnim opterećenjima. Ključne tačke na koje treba obratiti pažnju: (Dijagram prikazuje arhitekturu sa Load Balancer-om, API Gateway-jem, Message Queue-om, Service-om, Cache-om, Database-om, Object Storage-om i CDN-om)

sobes.tech АИ

Одговор од АИ

Для проектирования масштабируемого мессенджера с такими требованиями нужно учесть несколько ключевых аспектов:

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

Претходно Следеће