Plānojot mēru skalojamu ziņojumapmaiņas sistēmu, kas atbalsta 150 miljonus lietotāju, ar 75 miljoniem DAU, 225 miljoniem MAU, 1,2 miljoniem peak QPS lasīšanai / 300k rakstīšanai, 5 miljoniem vienlaicīgu lietotāju, ar 60 PB jauniem datiem gadā, 30% gada pieaugumu, SLA 99,95%, p99 <200 ms lasīšanai, <300 ms rakstīšanai. KONTEKSTS Nepieciešams izstrādāt izplatītu ziņojumapmaiņas sistēmu, līdzīgu WhatsApp, kas atbalsta 1:1 un grupu tērzēšanu, nodrošina ziņojumu piegādi, parāda lietotāju tiešsaistes statusus un ļauj pārsūtīt multimediju failus (attēlus, video, audio). Sistēma jānodrošina ar augstu pieejamību un zemu latentumu, jāatbalsta augsts paralēlisms un jāskala globāli. FUNKCIONĀLIE PRASĪBAS - Atbalsts personīgajiem (1:1) un grupu tērzēšanas ar iespēju pievienot/noņemt dalībniekus - Teksta ziņojumu un multimediju failu sūtīšana un saņemšana Nav skaidri redzama end-to-end šifrēšanas mehānisma īstenošana pakalpojumu vai klientu līmenī, izņemot vispārēju piezīmi. - Trūkst skaidra apraksta par sharding un replikāciju datu bāzēs pēc chat_id vai user_id, lai nodrošinātu mērogojamību un kļūdu tolerance. - Nav skaidrs komponentu vai mehānisma offline ziņojumu sinhronizācijai un piegādes apstiprinājumiem. - Nav skaidrs, kā tiek veikta slodzes līdzsvarošana starp datu bāzēm un pakalpojumiem, īpaši virsotnes slodzēs. **Kritiskie punkti, kas jāņem vērā:**

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

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. Мониторинг и алертинг

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

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