Progettazione di un sistema di messaggistica scalabile che supporti 150 milioni di utenti, 75 milioni di DAU, 225 milioni di MAU, 1,2 milioni di QPS di lettura / 300k di scrittura in picco, 5 milioni di utenti simultanei, 60 PB di nuovi dati all'anno, crescita del 30% annuo, SLA del 99,95%, p99 <200 ms per la lettura, <300 ms per la scrittura. CONTESTO È necessario progettare un sistema di messaggistica distribuito, simile a WhatsApp, che supporti chat 1:1 e di gruppo, garantisca la consegna dei messaggi, mostri gli stati online degli utenti e consenta il trasferimento di file multimediali (foto, video, audio). Il sistema deve garantire alta disponibilità e bassa latenza, supportare un alto parallelismo e scalare a livello globale. REQUISITI FUNZIONALI - Supporto per chat personali (1:1) e di gruppo con possibilità di aggiungere/rimuovere partecipanti - Invio e ricezione di messaggi di testo e file multimediali Non si vede una implementazione chiara del meccanismo di crittografia end-to-end a livello di servizi o clienti, a parte una annotazione generale. - Mancanza di una descrizione esplicita di sharding e replica dei database per chat_id o user_id per scalabilità e tolleranza ai guasti. - Non c'è un componente o meccanismo chiaro per gestire la sincronizzazione offline dei messaggi e delle ricevute di consegna. - Non è chiaro come venga effettuato il bilanciamento del carico tra database e servizi, specialmente in caso di picchi di carico. **Punti critici da 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. Мониторинг и алертинг

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

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