150 million foydalanuvchiga mo support qiladigan, 75 million DAU, 225 million MAU, 1.2M o'qish / 300k yozish piki QPS, 5 million bir vaqtning o'zida foydalanayotgan foydalanuvchilar, yillik 60 PB yangi ma'lumotlar, yillik 30% o'sish, SLA 99.95%, p99 <200 ms o'qish uchun, <300 ms yozish uchun, kengaytiriladigan va global miqyosda ishlashga mo'ljallangan skalable xabar yuborish tizimi loyihalashtirish. KONTEKST WhatsApp ga o'xshash, 1:1 va guruh chatlarni qo'llab-quvvatlaydigan, xabarlarni yetkazib berishni ta'minlaydigan, foydalanuvchilarning onlayn holatini ko'rsatadigan va multimedia fayllarini (foto, video, audio) uzatishni ta'minlaydigan tarqatilgan xabar tizimini loyihalashtirish zarur. Tizim yuqori mavjudlik va past kechikishni ta'minlashi, yuqori parallelizmni qo'llab-quvvatlashi va global miqyosda kengayishi kerak. FUNKTSIONAL TALABLAR - Shaxsiy (1:1) va guruh chatlarni qo'llab-quvvatlash, ishtirokchilarni qo'shish/olib tashlash imkoniyati bilan - Matnli xabarlar va multimedia fayllarini yuborish va qabul qilish Xizmatlar yoki mijozlar darajasida end-to-end shifrlash mexanizmining aniq amalga oshirilishi ko'rinmayapti, umumiy yozuvdan tashqari. - chat_id yoki user_id bo'yicha ma'lumotlar bazalarini sharding va replikatsiyasining aniq ta'rifi yo'q, kengaytirilish va nosozlikka chidamlilik uchun. - Offline xabarlar va yetkazib berish qabul qiluvchilarini sinxronlashtirish uchun aniq komponent yoki mexanizm yo'q. - Yuk ortish paytida ma'lumotlar bazalari va xizmatlar o'rtasida yukni taqsimlash qanday amalga oshirilishini aniqlash qiyin. **Muhim nuqtalar:**

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

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

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

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