Тарҳрезии системаи паёмнависии масштабшаванда, ки 150 миллион корбарро дастгирӣ мекунад, бо 75 миллион DAU, 225 миллион MAU, 1.2М QPS баландтарин барои хондан / 300k барои навиштан, 5 миллион корбарон дар як вақт, 60 PB маълумоти навсоларо, 30% афзоиши солона, SLA 99.95%, p99 <200 мс барои хондан, <300 мс барои навиштан. Мавзӯъ Тарҳрезии системаи паёмнависии тақсимшаванда, монанд ба WhatsApp, ки чатҳои 1:1 ва гурӯҳиро дастгирӣ мекунад, таъмини расонидани паёмҳо, нишон додани ҳолати онлайн ва интиқоли файлҳои мултимедиявӣ (тасвирҳо, видеоҳо, овозҳо). Система бояд баландии дастрасӣ ва пастии таъхирро таъмин кунад, параллелизмро дастгирӣ кунад ва дар сатҳи ҷаҳонӣ масштаб кунад. Талаботи функсионалӣ - Дастгирии чатҳои шахсӣ (1:1) ва гурӯҳӣ бо имконияти илова кардан/баромадан аз иштирокчиён - Иҷро ва қабул кардани паёмҳои матнӣ ва файлҳои мултимедиявӣ Механизми шифргузории end-to-end дар сатҳи хизматрасонӣ ё муштариён равшан намоён нест, ба истиснои як қайд умумӣ. - Тавсифи равшан дар бораи sharding ва репликацияи базаҳои додаҳо дар асоси chat_id ё user_id барои масштабшавӣ ва тобоварӣ ба хатоҳо нест. - Компонент ё механизми равшан барои ҳамоҳангсозии offline-и паёмҳо ва расонидани расмҳо вуҷуд надорад. - Чӣ гуна баланс кардани бор байни базаҳои додаҳо ва хизматрасониҳо, махсусан дар вақти шиддатнокӣ, равшан нест. **Мавзӯъҳои муҳим барои баррасӣ:**

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

1. Шардинг и репликация данных

   • Разделение данных по user_id или chat_id для распределения нагрузки между базами.
   • Репликация для обеспечения отказоустойчивости и быстрого чтения.

2. Обработка офлайн-синхронизации и delivery receipts

   • Хранение сообщений на сервере до подтверждения доставки.
   • Механизмы push-уведомлений и синхронизации при повторном подключении.

3. Балансировка нагрузки

   • Использование балансировщиков на уровне API и сервисов.
   • Горизонтальное масштабирование микросервисов.

4. Обеспечение SLA и низкой задержки

   • Кэширование часто запрашиваемых данных (например, online-статусов).
   • Использование быстрых хранилищ (in-memory, NoSQL) для сообщений и статусов.

5. Мультимедийные файлы

   • Отдельное хранилище (CDN, Object Storage) для медиа.
   • Асинхронная загрузка и доставка.

6. Безопасность

   • End-to-end шифрование желательно реализовать на клиенте.
   • Сервер отвечает за маршрутизацию и хранение зашифрованных данных.

7. Архитектура сервисов

   • Микросервисный подход: отдельные сервисы для сообщений, пользователей, мультимедиа, уведомлений.
   • Очереди сообщений (Kafka, RabbitMQ) для обработки пиковых нагрузок.

8. Мониторинг и алертинг

   • Метрики производительности, задержек, ошибок.
   • Автоматическое масштабирование при росте нагрузки.

В итоге, архитектура должна быть распределённой, с чётким разделением ответственности, поддержкой горизонтального масштабирования и высокой доступности. Особое внимание стоит уделить механизмам доставки сообщений, синхронизации офлайн-пользователей и эффективному хранению больших объёмов данных.