Projekt skalowalnego systemu wiadomości obsługującego 150 mln użytkowników, 75 mln DAU, 225 mln MAU, 1,2 mln odczytów / 300 tys. zapisów szczytowych QPS, 5 mln użytkowników jednocześnie, 60 PB nowych danych rocznie, roczny wzrost o 30%, SLA 99,95%, p99 <200 ms dla odczytu, <300 ms dla zapisu. KONTEKST Należy zaprojektować rozproszony system wiadomości, podobny do WhatsApp, obsługujący czaty 1:1 i grupowe, zapewniający dostarczanie wiadomości, wyświetlanie statusów online użytkowników i przesyłanie plików multimedialnych (zdjęcia, wideo, audio). System musi zapewniać wysoką dostępność i niskie opóźnienia, obsługiwać wysoki poziom równoległości i skalować na poziomie globalnym. WYMAGANIA FUNKCYJNE - Obsługa czatów osobistych (1:1) i grupowych z możliwością dodawania/usuwania uczestników - Wysyłanie i odbieranie wiadomości tekstowych i plików multimedialnych Brak wyraźnej implementacji mechanizmu end-to-end encryption na poziomie usług lub klientów, poza ogólną adnotacją. - Brak wyraźnego opisu sharding i replikacji baz danych według chat_id lub user_id dla skalowalności i odporności na awarie. - Brak wyraźnego komponentu lub mechanizmu do obsługi offline'owej synchronizacji wiadomości i potwierdzeń dostarczenia. - Nie jest jasne, jak realizowane jest równoważenie obciążenia między bazami danych a usługami, szczególnie przy szczytowych obciążeniach. **Krytyczne punkty do rozważenia:**

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

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

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

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