Проектиране на мащабируема система за съобщения, която поддържа 150 милиона потребители, 75 милиона DAU, 225 милиона MAU, 1,2 милиона peak QPS за четене / 300k за писане, 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 за мащабируемост и отказоустойчивост. - Няма ясен компонент или механизъм за офлайн синхронизация на съобщения и потвърждения за доставка. - Не е ясно как се извършва балансът на натоварването между базите данни и услугите, особено при пикови натоварвания. **Критични точки за разглеждане:**

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

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

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

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