Skaidomaus kurti mastelį siuntimo sistemą, kuri palaiko 150 milijonų vartotojų, 75 milijonų DAU, 225 milijonų MAU, 1,2 milijono peak QPS skaitymo / 300k rašymo, 5 milijonų vienu metu naudotojų, 60 PB naujų duomenų per metus, 30% metinį augimą, SLA 99,95%, p99 <200 ms skaitymui, <300 ms rašymui. KONTEKSTAS Reikia sukurti paskirstytą žinučių sistemą, panašią į WhatsApp, kuri palaiko 1:1 ir grupinius pokalbius, užtikrina žinučių pristatymą, rodo naudotojų būsenas ir leidžia perduoti multimedijos failus (nuotraukas, vaizdo įrašus, garsus). Sistema turi užtikrinti aukštą prieinamumą ir žemą delsą, palaikyti didelį paralelizmą ir būti skalaujama globaliai. FUNKCINIAI REIKALAVIMAI - Palaikymas asmeninių (1:1) ir grupinių pokalbių su galimybe pridėti/pašalinti dalyvius - Tekstinių žinučių ir multimedijos failų siuntimas ir gavimas Aiškus end-to-end šifravimo mechanizmo įgyvendinimas paslaugų ar klientų lygyje nėra matomas, išskyrus bendrą pastabą. - Trūksta aiškaus aprašymo apie sharding ir replikaciją duomenų bazėse pagal chat_id ar user_id, siekiant mastelio ir atsparumo klaidoms. - Nėra aiškios komponento ar mechanizmo offline žinučių sinchronizacijai ir pristatymo patvirtinimams. - Neaišku, kaip vyksta apkrovos paskirstymas tarp duomenų bazių ir paslaugų, ypač piko metu. **Kritinės vietos, kurias reikėtų apsvarstyti:**

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

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

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

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