Dizajn skalabilnog sistema za razmenu poruka koji podržava 150 miliona korisnika, 75 miliona DAU, 225 miliona MAU, 1.2M peak QPS za čitanje / 300k za pisanje, 5 miliona istovremenih korisnika, 60 PB novih podataka godišnje, rast od 30% godišnje, SLA 99.95%, p99 <200 ms za čitanje, <300 ms za pisanje. KONTEKST Potrebno je dizajnirati distribuirani sistem za razmenu poruka, sličan WhatsApp-u, koji podržava 1:1 i grupne razgovore, obezbeđuje dostavu poruka, prikazuje online statuse korisnika i omogućava prenos multimedijalnih fajlova (fotografije, video, audio). Sistem mora obezbediti visoku dostupnost i nisku latenciju, podržavati visok paralelizam i skalirati na globalnom nivou. FUNKCIONALNI ZAHTEVI - Podrška za lične (1:1) i grupne razgovore sa mogućnošću dodavanja/uklanjanja učesnika - Slanje i primanje tekstualnih poruka i multimedijalnih fajlova Nije jasno implementiran mehanizam end-to-end enkripcije na nivou servisa ili klijenata, osim opšte napomene. - Nedostaje eksplicitni opis sharding-a i replikacije baza podataka po chat_id ili user_id radi skalabilnosti i otpornosti na greške. - Nema jasnog komponenta ili mehanizma za offline sinhronizaciju poruka i potvrda isporuke. - Nije jasno kako se vrši balansiranje opterećenja između baza podataka i servisa, posebno u vršnim periodima. **Kritične tačke za razmatranje:**

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

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

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

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