Մասշտաբային հաղորդագրության համակարգի նախագծում, որը աջակցում է 150 միլիոն օգտվողի, 75 միլիոն DAU, 225 միլիոն MAU, 1.2 միլիոն ընթերցում / 300k գրառում QPS, 5 միլիոն միաժամանակյա օգտվող, 60 PB նոր տվյալներ տարեկան, տարեկան աճ 30%, P99 <200 միլիսեկունդ ընթերցման համար, <300 միլիսեկունդ գրելու համար, SLA 99.95%: ԿԵՆՏԱԿՍ Պետք է նախագծել տարածված հաղորդագրության համակարգ, նման WhatsApp-ին, որը աջակցում է 1:1 և խմբային զրույցներ, ապահովում է հաղորդագրությունների առաքումը, օգտվողների առցանց վիճակների ցուցադրումը և բազմամեդիա ֆայլերի փոխանցումը (նկարներ, տեսանյութեր, ձայն): Համակարգը պետք է ապահովի բարձր հասանելիություն և ցածր ուշացում, աջակցի բարձր համաժամանակություն և գլոբալ մակարդակով ընդլայնվի: Ֆունկցիոնալ պահանջներ - Աջակցություն անձնական (1:1) և խմբային զրույցների, մասնակցիներ ավելացնելու/հանելու հնարավորությամբ - Տեքստային հաղորդագրությունների և բազմամեդիա ֆայլերի ուղարկում և ստացում Նեֆունկցիոնալ պահանջներ - Չկա հստակ end-to-end կոդավորումը ծառայությունների կամ հաճախորդների մակարդակով, բացի ընդհանուր նշումից: - Չկա հստակ նկարագրություն sharding և ռեպլիկացիայի մասին chat_id կամ user_id-ի համար՝ ընդլայնելիության և սխալների դիմացկունության համար: - Չկա հստակ բաղադրիչ կամ մեխանիզմ offline հաղորդագրությունների սինխրոնիզացիայի և առաքման մասին: - Չի պարզ, թե ինչպես է կատարվում բեռի հավասարակշռությունը տվյալների բազաների և ծառայությունների միջև, հատկապես գագաթնակետային բեռների ժամանակ: **Կարևոր կետեր, որոնք պետք է հաշվի առնեն:** (Արքիտեկտուրայի դիագրամը ցույց է տալիս Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage և CDN)

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

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