Senior

Progettazione di un sistema di messaggistica scalabile che supporti 150 milioni di utenti, 75 milioni di DAU, 225 milioni di MAU, 1,2 milioni di letture / 300k scritture QPS, 5 milioni di utenti simultanei, 60 PB di nuovi dati all'anno, crescita del 30% annuo, P99 <200 ms per la lettura, <300 ms per la scrittura, SLA 99,95%. CONTESTO È necessario progettare un sistema di messaggistica distribuito, simile a WhatsApp, che supporti chat 1:1 e di gruppo, garantisca la consegna dei messaggi, visualizzi gli stati online degli utenti e trasmetta file multimediali (foto, video, audio). Il sistema deve garantire alta disponibilità e bassa latenza, supportare alto parallelismo e scalare a livello globale. REQUISITI FUNZIONALI - Supporto per chat personali (1:1) e di gruppo con possibilità di aggiungere/rimuovere partecipanti - Invio e ricezione di messaggi di testo e file multimediali Requisiti non funzionali: - Nessuna implementazione esplicita di crittografia end-to-end a livello di servizi o client, tranne un'annotazione generale. - Mancanza di una descrizione chiara dello sharding e della replica dei database per chat_id o user_id per scalabilità e tolleranza ai guasti. - Nessun componente o meccanismo esplicito per gestire la sincronizzazione offline dei messaggi e le ricevute di consegna. - Non è chiaro come venga effettuato il bilanciamento del carico tra database e servizi, specialmente durante i picchi di traffico. Punti critici da considerare: (Il diagramma mostra un'architettura con Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage e CDN)

sobes.tech AI

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

Precedente Avanti