Մասին՝ 150 միլիոն օգտվողների աջակցությամբ, 75 միլիոն DAU, 225 միլիոն MAU, 1.2M ընթերցում / 300k գրառումներ բարձր QPS, 5 միլիոն միաժամանակյա օգտվող, տարեկան 60 PB նոր տվյալներ, տարեկան 30% աճ, SLA 99.95%, p99 <200 ms ընթերցման համար, <300 ms գրառման համար: ԿԵՆՏԱԿՍՏ Պետք է նախագծել բաշխված հաղորդագրությունների համակարգ, որը նման է 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. Мониторинг и алертинг

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

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