Entwurf eines skalierbaren Messaging-Systems, das 150 Millionen Nutzer, 75 Millionen DAU, 225 Millionen MAU, 1,2 Mio. Lese- / 300k Schreib-Peak-QPS, 5 Millionen gleichzeitige Nutzer, 60 PB neue Daten pro Jahr, 30% jährliches Wachstum, SLA 99,95%, p99 <200 ms für Lesen, <300 ms für Schreiben unterstützt. KONTEXT Es ist erforderlich, ein verteiltes Messaging-System zu entwerfen, ähnlich wie WhatsApp, das 1:1- und Gruppen-Chats unterstützt, die Zustellung von Nachrichten gewährleistet, Online-Status der Nutzer anzeigt und die Übertragung von Multimedia-Dateien (Fotos, Videos, Audio) ermöglicht. Das System muss hohe Verfügbarkeit und niedrige Latenz bieten, hohen Parallelismus unterstützen und global skalieren. FUNKTIONALE ANFORDERUNGEN - Unterstützung für persönliche (1:1) und Gruppen-Chats mit der Möglichkeit, Teilnehmer hinzuzufügen/zu entfernen - Versand und Empfang von Textnachrichten und Multimedia-Dateien Es ist keine klare Implementierung eines End-to-End-Verschlüsselungsmechanismus auf Service- oder Client-Ebene sichtbar, abgesehen von einer allgemeinen Anmerkung. - Es fehlt eine explizite Beschreibung von Sharding und Replikation der Datenbanken nach chat_id oder user_id für Skalierbarkeit und Fehlertoleranz. - Es gibt keinen klaren Komponenten- oder Mechanismus für die Offline-Synchronisierung von Nachrichten und Delivery-Receipts. - Es ist unklar, wie die Lastverteilung zwischen Datenbanken und Diensten, insbesondere bei Spitzenbelastungen, erfolgt. **Kritische Punkte, die beachtet werden sollten:**

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

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. Мониторинг и алертинг

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

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