Senior

Тарҳрезии системаи паёмнависии масштабшаванда, ки 150 миллион корбарро дастгирӣ мекунад, 75 миллион DAU, 225 миллион MAU, 1.2 миллион хондан / 300k навишт QPS, 5 миллион корбарони ҳамзамон, 60 PB маълумоти нав дар сол, 30% афзоиш дар сол, P99 <200 мс барои хондан, <300 мс барои навишт, SLA 99.95%. Мавзӯъ Талаб карда мешавад, ки системаи паёмнависии тақсимшуда, монанди WhatsApp, тарҳрезӣ карда шавад, ки ҳам чатҳои 1:1 ва гурӯҳӣ, таъмини расонидани паёмҳо, намоиши статусҳои онлайн ва интиқоли файлҳои мултимедиявӣ (тасвирҳо, видеоҳо, овозҳо)ро дастгирӣ мекунад. Система бояд дастрасии баланд ва таъхири пастро таъмин кунад, параллелизмро дастгирӣ кунад ва дар сатҳи глобалӣ васеъ шавад. Талаботи функсионалӣ - Дастгирии чатҳои шахсӣ (1:1) ва гурӯҳӣ бо имконияти илова кардан/ҳамроҳ кардани иштирокчиён - Иҷро ва қабул кардани паёмҳои матнӣ ва файлҳои мултимедиявӣ Талаботи ғайрифунксионалӣ: - Ҳеҷ гуна татбиқи равшан барои рамзгузории охир ба охир дар сатҳи хизматрасонӣ ё муштариён, ба истиснои қайд умумӣ. - Тавсифи равшан дар бораи sharding ва репликаи базаҳои додаҳо бо chat_id ё user_id барои масштабшавӣ ва тобоварӣ ба хатоҳо вуҷуд надорад. - Ҳеҷ гуна компонент ё механизм барои ҳамоҳангсозии offline паёмҳо ва расонидани расмҳо вуҷуд надорад. - Чӣ гуна баланс кардани бор байни базаҳои додаҳо ва хизматрасониҳо, махсусан дар вақти шиддатнокӣ, равшан нест. Масъалаҳои муҳим, ки бояд ба назар гирифта шаванд: (Диаграмма архитектура бо Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage ва CDN нишон дода шудааст)

sobes.tech AI

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

Гузашта Оянда