Senior

Ontwerp een schaalbare berichtenapplicatie die 150 miljoen gebruikers ondersteunt, met 75 miljoen DAU, 225 miljoen MAU, 1.2M lees- / 300k schrijfsnelheid QPS, 5 miljoen gelijktijdige gebruikers, 60 PB nieuwe gegevens per jaar, een jaarlijkse groei van 30%, P99 <200 ms voor lezen, <300 ms voor schrijven, SLA 99.95%. CONTEXT Het is nodig om een gedistribueerd berichten systeem te ontwerpen, vergelijkbaar met WhatsApp, dat 1-op-1 en groepschats ondersteunt, berichten bezorgt, online statussen van gebruikers toont en multimedia bestanden (foto's, video's, audio) verzendt. Het systeem moet hoge beschikbaarheid en lage latency garanderen, hoge paralleliteit aankunnen en wereldwijd schaalbaar zijn. FUNCTIONELE EISEN - Ondersteuning voor persoonlijke (1:1) en groepschats met mogelijkheid tot toevoegen/verwijderen van deelnemers - Verzenden en ontvangen van tekstberichten en multimedia bestanden Niet-functionele eisen: - Geen expliciete implementatie van end-to-end encryptie mechanisme op servicelagen of clients, behalve een algemene annotatie. - Geen expliciete beschrijving van sharding en replicatie van databases op basis van chat_id of user_id voor schaalbaarheid en fouttolerantie. - Geen expliciete component of mechanisme voor offline berichtensynchronisatie en afleveringsbevestigingen. - Het is niet duidelijk hoe load balancing wordt uitgevoerd tussen databases en services, vooral tijdens piekbelastingen. Kritieke punten om op te letten: (De diagram toont een architectuur met Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage en CDN)

sobes.tech AI

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

Vorige Volgende