Proiectarea unui sistem de mesagerie scalabil care suportă 150 milioane de utilizatori, 75 milioane DAU, 225 milioane MAU, 1,2 milioane QPS de citire / 300k de scriere în vârf, 5 milioane de utilizatori simultani, 60 PB de date noi pe an, creștere de 30% anual, SLA 99,95%, p99 <200 ms pentru citire, <300 ms pentru scriere. CONTEXT Este necesar să proiectăm un sistem de mesagerie distribuit, similar cu WhatsApp, care suportă chat-uri 1:1 și de grup, asigură livrarea mesajelor, afișează statusurile online ale utilizatorilor și permite transferul de fișiere multimedia (poze, videoclipuri, audio). Sistemul trebuie să asigure disponibilitate ridicată și latență scăzută, să suporte un paralelism înalt și să scaleze la nivel global. CERINȚE FUNCȚIONALE - Suport pentru chat-uri personale (1:1) și de grup cu posibilitatea de a adăuga/elimina participanți - Trimiterea și primirea de mesaje text și fișiere multimedia Nu se observă o implementare clară a mecanismului de criptare end-to-end la nivel de servicii sau clienți, în afară de o notă generală. - Lipsește o descriere explicită a sharding-ului și replicării bazelor de date după chat_id sau user_id pentru scalabilitate și toleranță la defecte. - Nu există un component sau mecanism clar pentru gestionarea sincronizării offline a mesajelor și a confirmărilor de livrare. - Nu este clar cum se face echilibrarea încărcăturii între baze de date și servicii, mai ales în perioadele de vârf. **Puncte critice de luat în considerare:**

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

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

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

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