Skálázható üzenetküldő rendszer tervezése, amely támogatja a 150 millió felhasználót, 75 millió DAU-t, 225 millió MAU-t, 1,2 millió olvasási / 300k írási csúcs QPS-t, 5 millió egyidejű felhasználót, évente 60 PB új adatot, 30%-os éves növekedést, 99,95%-os SLA-t, p99 <200 ms olvasásra, <300 ms írásra. KÖRNYEZET Olyan elosztott üzenetküldő rendszer tervezése szükséges, mint a WhatsApp, amely támogatja az 1:1 és csoportos beszélgetéseket, garantálja az üzenetek kézbesítését, megjeleníti a felhasználók online státuszát, és lehetővé teszi multimédia fájlok (képek, videók, hangok) átvitelét. A rendszernek magas rendelkezésre állást és alacsony késleltetést kell biztosítania, támogatnia kell a magas párhuzamosságot, és globálisan skálázhatónak kell lennie. FUNKCIÓS KÖVETELMÉNYEK - Személyes (1:1) és csoportos beszélgetések támogatása, résztvevők hozzáadása/eltávolítása lehetőséggel - Szöveges üzenetek és multimédia fájlok küldése és fogadása Nincs világos end-to-end titkosítási mechanizmus megvalósítása szolgáltatási vagy kliens szinten, általános megjegyzésen kívül. - Hiányzik egyértelmű leírás a shardingról és a replikációról chat_id vagy user_id szerint az skálázhatóság és hibatűrés érdekében. - Nincs világos komponens vagy mechanizmus az offline üzenet-szinkronizáció és kézbesítési igazolások kezelésére. - Nem világos, hogyan történik a terheléselosztás az adatbázisok és a szolgáltatások között, különösen csúcsidőszakokban. **Kritikus pontok, amelyeket figyelembe kell venni:**

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

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

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

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