მასშტაბირებადი შეტყობინების სისტემის პროექტირება, რომელიც მხარს უჭერს 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 мс записи необходимо оптимизировать пути данных, использовать кэширование и асинхронную обработку сообщений.