150 milyon kullanıcı, 75 milyon DAU, 225 milyon MAU, 1.2M okuma / 300k yazma zirvesi QPS, 5 milyon eşzamanlı kullanıcı, yılda 60 PB yeni veri, yıllık %30 büyüme, %99.95 SLA, p99 <200 ms okuma için, <300 ms yazma için destekleyen ölçeklenebilir bir mesajlaşma sistemi tasarımı. KONTEXT WhatsApp benzeri, 1:1 ve grup sohbetleri destekleyen, mesaj teslimini sağlayan, kullanıcıların çevrimiçi durumlarını gösteren ve multimedya dosyalarının (fotoğraf, video, ses) iletimini sağlayan dağıtık bir mesajlaşma sistemi tasarlamak gerekiyor. Sistem yüksek kullanılabilirlik ve düşük gecikme sağlamalı, yüksek paralellik desteklemeli ve küresel ölçekte ölçeklenebilir olmalı. FONKSİYONEL GEREKSİNİMLER - Kişisel (1:1) ve grup sohbetleri desteği, katılımcı ekleme/çıkarma imkanı - Metin mesajları ve multimedya dosyalarının gönderimi ve alınması Servisler veya istemciler seviyesinde end-to-end şifreleme mekanizmasının açık bir uygulaması görünmüyor, genel bir not dışında. - chat_id veya user_id'ye göre veritabanlarının sharding ve replikasyonunun açık bir tanımı yok, ölçeklenebilirlik ve arıza toleransı için. - Çevrimdışı mesaj senkronizasyonu ve teslim raporlarını işlemek için açık bir bileşen veya mekanizma yok. - Özellikle zirve yüklerde, veritabanları ve servisler arasında yük dengelemenin nasıl yapıldığı net değil. **Dikkate alınması gereken kritik noktalar:**

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

1. Шардинг и репликация данных

   • Разделение данных по user_id или chat_id для распределения нагрузки между базами.
   • Репликация для обеспечения отказоустойчивости и быстрого чтения.

2. Обработка офлайн-синхронизации и delivery receipts

   • Хранение сообщений на сервере до подтверждения доставки.
   • Механизмы push-уведомлений и синхронизации при повторном подключении.

3. Балансировка нагрузки

   • Использование балансировщиков на уровне API и сервисов.
   • Горизонтальное масштабирование микросервисов.

4. Обеспечение SLA и низкой задержки

   • Кэширование часто запрашиваемых данных (например, online-статусов).
   • Использование быстрых хранилищ (in-memory, NoSQL) для сообщений и статусов.

5. Мультимедийные файлы

   • Отдельное хранилище (CDN, Object Storage) для медиа.
   • Асинхронная загрузка и доставка.

6. Безопасность

   • End-to-end шифрование желательно реализовать на клиенте.
   • Сервер отвечает за маршрутизацию и хранение зашифрованных данных.

7. Архитектура сервисов

   • Микросервисный подход: отдельные сервисы для сообщений, пользователей, мультимедиа, уведомлений.
   • Очереди сообщений (Kafka, RabbitMQ) для обработки пиковых нагрузок.

8. Мониторинг и алертинг

   • Метрики производительности, задержек, ошибок.
   • Автоматическое масштабирование при росте нагрузки.

В итоге, архитектура должна быть распределённой, с чётким разделением ответственности, поддержкой горизонтального масштабирования и высокой доступности. Особое внимание стоит уделить механизмам доставки сообщений, синхронизации офлайн-пользователей и эффективному хранению больших объёмов данных.