Ontwerp van een schaalbaar berichtenplatform dat 150 miljoen gebruikers ondersteunt, met 75 miljoen DAU, 225 miljoen MAU, 1,2 miljoen lees- / 300k schrijfsituaties QPS, 5 miljoen gelijktijdige gebruikers, 60 PB nieuwe gegevens per jaar, 30% jaarlijkse groei, SLA 99,95%, p99 <200 ms voor lezen, <300 ms voor schrijven. CONTEXTE Het is nodig om een gedistribueerd berichtenplatform te ontwerpen, vergelijkbaar met WhatsApp, dat 1:1 en groepschats ondersteunt, berichtbezorging garandeert, online statussen van gebruikers toont en multimedia-bestanden (foto's, video's, audio) overdraagt. Het systeem moet hoge beschikbaarheid en lage latentie bieden, hoge paralleliteit ondersteunen en wereldwijd schalen. FUNCTIONELE EISEN - Ondersteuning voor persoonlijke (1:1) en groepschats met de mogelijkheid om deelnemers toe te voegen/verwijderen - Verzenden en ontvangen van tekstberichten en multimedia-bestanden Er lijkt geen duidelijke implementatie van end-to-end encryptie-mechanismen op servicetoe of clientniveau, afgezien van een algemene notitie. - Er ontbreekt een expliciete beschrijving van sharding en replicatie van databases op basis van chat_id of user_id voor schaalbaarheid en fouttolerantie. - Er is geen duidelijke component of mechanisme voor offline synchronisatie van berichten en afleverbevestigingen. - Het is niet duidelijk hoe de load balancing tussen databases en services wordt uitgevoerd, vooral bij piekbelastingen. **Kritieke punten om rekening mee te houden:**

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

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

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

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