Dizajn skalovateľného systému správ, ktorý podporuje 150 miliónov používateľov, 75 miliónov DAU, 225 miliónov MAU, 1,2 milióna peak QPS čítania / 300k zápisov, 5 miliónov súčasných používateľov, 60 PB nových dát ročne, rast o 30 % ročne, SLA 99,95 %, p99 <200 ms pre čítanie, <300 ms pre zápis. KONTEXT Je potrebné navrhnúť distribuovaný systém správ, podobný WhatsApp, ktorý podporuje 1:1 a skupinové chaty, zabezpečuje doručovanie správ, zobrazuje online stavy používateľov a umožňuje prenos multimediálnych súborov (fotky, videá, audio). Systém musí zabezpečiť vysokú dostupnosť a nízku latenciu, podporovať vysoký paralelizmus a škálovať na globálnej úrovni. POŽIADAVKY NA FUNKCIE - Podpora osobných (1:1) a skupinových chatov s možnosťou pridávať/odstraňovať účastníkov - Odosielanie a prijímanie textových správ a multimediálnych súborov Nie je jasná implementácia end-to-end šifrovania na úrovni služieb alebo klientov, okrem všeobecnej poznámky. - Chýba jasný opis sharding a replikácie databáz podľa chat_id alebo user_id pre škálovateľnosť a odolnosť voči chybám. - Nie je jasný komponent alebo mechanizmus pre offline synchronizáciu správ a potvrdení doručenia. - Nie je jasné, ako sa vykonáva vyvažovanie záťaže medzi databázami a službami, najmä pri špičkových zaťaženiach. **Kritické body na zváženie:**

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

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

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

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