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) жана топтук чаттарды колдоо, катышуучуларды кошуу/алып салуу мүмкүнчүлүгү менен - Тексттик билдирүүлөрдү жана мультимедиалык файлдарды жөнөтүү жана кабыл алуу Нефункционалдуу талаптар: - Кызматтар же кардарлар деңгээлинде end-to-end шифрлөө так ишке ашырылбайт, жалпы белгилөө менен гана. - chat_id же user_id боюнча базалардын sharding жана репликациясы так сүрөттөлбөйт, масштабдуулук жана каталарга туруктуулук үчүн. - 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 мс записи необходимо оптимизировать пути данных, использовать кэширование и асинхронную обработку сообщений.

Мурунку Кийинки