Senior

150 milyon istifadəçiyə dəstək verən, 75 milyon DAU, 225 milyon MAU, 1.2M oxuma / 300k yazma QPS, 5 milyon eyni vaxtda istifadəçi, ildə 60 PB yeni məlumat, illik 30% artım, P99 <200 ms oxuma üçün, <300 ms yazma üçün, SLA 99.95% dəstəkləyən miqyaslana bilən mesajlaşma sistemi layihələndirin. KONTEXT WhatsApp-ə bənzər, mesajların çatdırılmasını təmin edən, istifadəçilərin onlayn statuslarını göstərən və multimedia fayllarını (şəkil, video, audio) ötürən paylanmış mesajlaşma sistemi layihələndirmək lazımdır. Sistem yüksək əlçatanlıq və aşağı gecikmə təmin etməli, yüksək paralelliyi dəstəkləməli və qlobal miqyasda genişlənə bilməlidir. FUNKSİONAL TƏLƏBLƏR - 1:1 və qrup söhbətləri dəstəyi, iştirakçıların əlavə və ya çıxarılması imkanı ilə - Mətn mesajlarının və multimedia fayllarının göndərilməsi və alınması Qeyri-funksional tələblər: - Servis və ya müştərilərdə end-to-end şifrələmə mexanizminin açıq tətbiqi yoxdur, ümumi qeyd ilə xaric. - chat_id və ya user_id əsasında verilənlər bazalarının sharding və replikasiyasının açıq şəkildə təsviri yoxdur, miqyaslana bilənlik və uğursuzluğa davamlılıq üçün. - Offline mesajların sinxronizasiyası və çatdırılma hesabatları üçün açıq komponent və ya mexanizm yoxdur. - Yük balanslaşdırmanın verilənlər bazaları və xidmətlər arasında, xüsusən pik vaxtlarda necə həyata keçirildiyi aydın deyil. Diqqət yetirilməli olan nöqtələr: (Diagramda Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage və CDN ilə arxitektura göstərilir.)

sobes.tech Süni İntellekt

AI-dan cavab

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

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

Əvvəlki Növbəti