Senior

Skálázható üzenetküldő rendszer tervezése, amely 150 millió felhasználót támogat, 75 millió DAU, 225 millió MAU, 1.2M olvasás / 300k írás QPS, 5 millió egyidejű felhasználó, évente 60 PB új adat, 30%-os éves növekedés, P99 <200 ms olvasásra, <300 ms írásra, SLA 99.95%. KÖRNYEZET Olyan elosztott üzenetküldő rendszer tervezése szükséges, mint a WhatsApp, amely támogatja az 1:1 és csoportos chat-eket, biztosítja az üzenetek kézbesítését, megjeleníti a felhasználók online státuszát és multimédiás fájlokat (képek, videók, hangok) továbbít. A rendszer magas rendelkezésre állást és alacsony késleltetést kell, hogy biztosítson, magas párhuzamosságot kell, hogy kezeljen, és globálisan skálázható legyen. FUNKCIONÁLIS KÖVETELMÉNYEK - Támogatás személyes (1:1) és csoportos chat-ekhez, lehetőséggel résztvevők hozzáadására/eltávolítására - Szöveges üzenetek és multimédiás fájlok küldése és fogadása Nem-funkcionális követelmények: - Nincs kifejezett end-to-end titkosítási mechanizmus a szolgáltatások vagy kliensek szintjén, kivéve egy általános megjegyzést. - Nincs kifejezett leírás a shardingról és a replikációról chat_id vagy user_id alapján az skálázhatóság és a hibatűrés érdekében. - Nincs kifejezett komponens vagy mechanizmus az offline üzenet szinkronizációhoz és kézbesítési igazolásokhoz. - Nem világos, hogyan történik a terheléselosztás az adatbázisok és a szolgáltatások között, különösen csúcsidőben. Kritikus pontok, amikre figyelni kell: (A diagramon Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage és CDN szerepel.)

sobes.tech MI

Válasz az MI-től

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

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

Korábbi Következő