Senior

Entwurf eines skalierbaren Messaging-Systems, das 150 Millionen Nutzer, 75 Millionen DAU, 225 Millionen MAU, 1,2 Mio. Lese- / 300k Schreib-QPS, 5 Millionen gleichzeitige Nutzer, 60 PB neue Daten pro Jahr, jährliches Wachstum von 30 %, P99 <200 ms für Lesen, <300 ms für Schreiben, SLA 99,95 % 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 Multimedia-Dateien (Fotos, Videos, Audio) überträgt. Das System muss hohe Verfügbarkeit und niedrige Latenz gewährleisten, 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 Nicht-funktionale Anforderungen: - Es gibt keine explizite Implementierung von End-to-End-Verschlüsselung auf Service- oder Client-Ebene, außer einer allgemeinen Anmerkung. - Es gibt keine klare Beschreibung von Sharding und Replikation der Datenbanken nach chat_id oder user_id für Skalierbarkeit und Fehlertoleranz. - Es gibt keine explizite Komponente oder Mechanismus zur Offline-Synchronisation von Nachrichten und Delivery-Receipts. - Es ist nicht ersichtlich, wie die Lastverteilung zwischen Datenbanken und Diensten, insbesondere bei Spitzenbelastungen, umgesetzt wird. Kritische Punkte, auf die geachtet werden sollte: (Diagramm zeigt eine Architektur mit Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage und CDN)

sobes.tech KI

Antwort von AI

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

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

Zurück Als nächstes