Senior

Ölçeklenebilir bir mesajlaşma uygulaması tasarlayın; 150 milyon kullanıcı, 75 milyon DAU, 225 milyon MAU, 1.2M okuma / 300k yazma QPS, 5 milyon eşzamanlı kullanıcı, yılda 60 PB yeni veri, yıllık %30 büyüme, P99 <200 ms okuma, <300 ms yazma, SLA %99.95. KONTEXT WhatsApp benzeri, mesaj iletimi, kullanıcıların çevrimiçi durumlarının gösterimi ve multimedya dosyalarının (foto, video, ses) iletimi sağlayan dağıtılmış bir mesajlaşma sistemi tasarlamak gerekiyor. Sistem yüksek erişilebilirlik ve düşük gecikme sağlamalı, yüksek paralellik desteklemeli ve küresel ölçekte ölçeklenebilir olmalı. FONKSİYONEL GEREKSİNİMLER - 1:1 ve grup sohbetleri desteği, katılımcı ekleme/çıkarma imkanıyla - Metin mesajları ve multimedya dosyalarının gönderimi ve alınması Fonksiyonel olmayan gereksinimler: - Servisler veya istemciler seviyesinde uçtan uca şifreleme mekanizması açıkça uygulanmamış, genel bir notasyon dışında. - chat_id veya user_id bazında veritabanlarının sharding ve replikasyonunun açıkça tanımlanmamış olması, ölçeklenebilirlik ve arıza toleransı için. - Çevrimdışı mesaj senkronizasyonu ve teslim raporları için açık bir bileşen veya mekanizma bulunmuyor. - Yük dengelemenin veritabanları ve servisler arasında özellikle yoğun zamanlarda nasıl yapıldığı net değil. Dikkat edilmesi gereken noktalar: (Diagramda Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage ve CDN içeren mimari gösterilmektedir.)

sobes.tech yapay zeka

AI'dan gelen yanıt

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

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

Önceki Sonraki