Проектирование системы новостного портала с ИИ-ассистентами (как РБК) в экосистеме Сбера

1. Функциональные требования

Пользовательские сценарии

• Просмотр ленты новостей – пользователь видит персонализированную или общую ленту новостей, сгруппированную по категориям (экономика, технологии, спорт и т.д.) и тегам.
• Поиск новостей – полнотекстовый поиск по заголовкам, текстам, авторам, датам.
• Чтение новости – отображение полного текста, изображений, видео, ссылок на связанные материалы.
• Взаимодействие с ИИ-ассистентом – возможность задать вопрос по тексту новости, получить краткое содержание, объяснение сложных терминов, подбор связанных событий или прогнозы (аналитика). Ассистент может быть активирован голосом или текстом.
• Персонализация – рекомендации новостей на основе истории просмотров, лайков, поведения.
• Сохранение в избранное – возможность откладывать новости для чтения позже.
• Шеринг – поделиться новостью через мессенджеры, соцсети.
• Уведомления – push-уведомления о важных событиях, новых статьях по подписке.
• Профиль – регистрация/авторизация через Сбер ID, управление предпочтениями, настройка категорий.

Административные и внутренние сценарии

• Управление контентом – создание, редактирование, публикация новостей через админ-панель.
• Модерация – автоматическая (с помощью ИИ) и ручная проверка контента на соответствие политикам, экстремизм, фейки.
• Интеграция с внешними источниками – автоматический сбор новостей по RSS/API от партнёров (включая РБК), парсинг и обработка.
• Аналитика – сбор статистики просмотров, активности пользователей, работы ИИ для улучшения моделей и бизнес-метрик.

2. Нефункциональные требования

• Доступность: целевой уровень SLA – 99.99% (не более 52 минут простоя в год). Исключение – возможные плановые работы.
• Производительность:
  Время ответа API (p95) для чтения новостей – не более 200 мс.
  Время ответа ИИ-ассистента (p95) – не более 2 секунд (для сложных запросов допустимо до 5 с, с индикацией обработки).
  Пропускная способность – поддержка пиковой нагрузки 24 000 RPS.
• Безопасность:
  Шифрование данных в покое и при передаче (TLS).
  Защита от DDoS, WAF, ограничение rate limit.
  Соответствие требованиям 152-ФЗ, PCI DSS (при работе с платежами, если есть), стандартам Сбера.
  Интеграция с системой управления доступом (Сбер ID, ролевая модель).
• Надёжность:
  Резервирование всех компонентов (multi-AZ, geo-redundancy).
  Регулярные автоматические бэкапы с возможностью point-in-time recovery.
  Graceful degradation – при отказе ИИ-сервисов пользователь видит обычную ленту.
• Масштабируемость: горизонтальное масштабирование микросервисов и баз данных, возможность добавления узлов без downtime.
• Наблюдаемость: централизованный сбор логов (ELK/Loki), метрик (Prometheus), трейсинг (Jaeger/Tempo); алертинг.
• Мультиканальность: поддержка веб-версии, мобильных приложений (iOS, Android), возможно интеграция с умными устройствами (СберСалют).
• Интеграция с экосистемой Сбера: использование Сбер ID для аутентификации, ассистентов Салют для голосового взаимодействия, возможная интеграция с платежными сервисами.

3. Продуктовые метрики

• Активность:
  DAU (Daily Active Users) / MAU (Monthly Active Users)
  Среднее время сессии
  Количество просмотренных новостей на пользователя в день
• Вовлечённость:
  CTR по рекомендациям (клики на предложенные новости)
  Количество сохранений, шерингов, комментариев
  Retention (1, 7, 30 дней)
• ИИ-ассистент:
  Количество обращений к ассистенту на пользователя
  Процент успешных ответов (оценка пользователем like/dislike)
  Конверсия в дочитывание новости после ответа ассистента
• Бизнес-метрики:
  Конверсия в подписку (если есть платный контент)
  LTV (LifeTime Value)
  Доля пользователей, использующих персонализацию

4. Список технологий

5. Архитектура в нотации C4 (Mermaid)

Контекстная диаграмма (уровень 1)

Диаграмма контейнеров (уровень 2)

6. Инфраструктура

• Кластер Kubernetes (k8s): развёрнут в нескольких зонах доступности (минимум 3 AZ) для обеспечения отказоустойчивости. Используется managed k8s от SberCloud или self-hosted.
• Балансировщики нагрузки: внешний (ALB/NGINX) для приёма трафика и распределения между узлами Gateway.
• Сеть: виртуальное облако (VPC) с сегментацией (публичная подсеть для Gateway, приватные для микросервисов и БД). Web Application Firewall (WAF) для защиты от OWASP Top 10.
• Хранилища:
  PostgreSQL: управляемый кластер с репликами для чтения, резервное копирование каждые 15 минут.
  Cassandra: multi-DC кластер для обеспечения глобальной доступности ленты.
  Redis: кластер Redis Sentinel или Redis Cluster для кэша и сессий.
  Elasticsearch: кластер из нескольких нод с горячими/тёплыми данными.
  ClickHouse: для аналитических отчётов, репликация.
  S3: объектное хранилище для изображений, видео, резервных копий.
• Мониторинг и логирование: Prometheus собирает метрики с k8s и микросервисов, Grafana для дашбордов. Loki для логов, Tempo для трейсинга. Alertmanager отправляет алерты в Telegram/email.
• CI/CD: GitLab CI, сборка Docker-образов, хранение в Harbour, деплой через ArgoCD (GitOps).
• Disaster Recovery: регулярные бэкапы в S3 с возможностью восстановления в другом регионе. Сценарии переключения трафика (DNS).

7. Количество микросервисов

Ориентировочно 15–20 микросервисов, каждый отвечает за свою ограниченную область:

1. Auth Service – аутентификация, авторизация, интеграция со Сбер ID.
2. User Service – управление профилями, подписками, настройками.
3. News Service – CRUD новостей, лента, кэширование, выдача по категориям.
4. Catalog Service – управление категориями, тегами, рубриками.
5. Search Service – полнотекстовый поиск (Elasticsearch).
6. Recommendations Service – выдача персональных рекомендаций (ML).
7. AI Assistant Service – обработка запросов к ИИ, интеграция с моделями NLP.
8. Moderation Service – автоматическая модерация текста и изображений.
9. Parser Service – парсинг внешних источников, нормализация данных.
10. Media Service – загрузка, обработка (resize, crop) и выдача медиафайлов.
11. Notification Service – отправка push, email, in-app уведомлений.
12. Analytics Service – сбор событий (клики, просмотры) в Kafka и запись в ClickHouse.
13. Comment Service – комментарии, лайки, избранное (социальные взаимодействия).
14. Gateway Service – единая точка входа, маршрутизация, rate limiting.
15. Config Service – централизованная конфигурация.
16. Service Discovery – Eureka / Consul (если не использовать k8s native).

Каждый микросервис разворачивается независимо и масштабируется отдельно.

8. Масштабирование системы

• Горизонтальное масштабирование микросервисов:
  Используем HPA (Horizontal Pod Autoscaler) в k8s на основе метрик CPU, памяти и пользовательских метрик (RPS, длина очереди).
  Для AI Assistant Service – автокейлинг на основе загрузки GPU (использование k8s device plugins).
• Базы данных:
  PostgreSQL: реплики чтения для распределения нагрузки SELECT; шардирование по tenant (например, по региону) если данных очень много.
  Cassandra: линейное масштабирование добавлением узлов.
  Elasticsearch: шардирование индексов, репликация.
  Redis: кластеризация (Redis Cluster) для кэша.
• Кэширование:
  Многоуровневое: CDN для статики и популярных новостей (заголовки, картинки), Redis для динамических данных (лента, результаты поиска), HTTP-кэширование на уровне Gateway.
• Асинхронность:
  Тяжёлые операции (парсинг, обработка ИИ, модерация) выполняются асинхронно через Kafka, ответ клиенту возвращается быстро с последующим обновлением через polling или WebSocket.
• Геораспределение:
  Кластеры k8s в нескольких дата-центрах (Москва, Санкт-Петербург) для минимизации задержек и отказоустойчивости. Балансировка трафика через GeoDNS.
• CDN: для раздачи изображений, видео, статических файлов – использование CDN провайдера (например, CloudFlare или собственные edge-серверы).

9. Нагрузка на расширение 24 000 RPS

Для обеспечения 24 000 RPS необходимо:

• Оценка распределения запросов:
  70% – чтение ленты и отдельных новостей (кэшируется)
  15% – поиск и рекомендации (требуют индексов)
  10% – взаимодействие с ИИ (тяжёлые запросы, требуют GPU)
  5% – запись (лайки, сохранения, комментарии)
• Мощности:
  API Gateway: несколько реплик (например, 20-30 инстансов) с балансировкой.
  News Service: кэширование в Redis позволяет обслуживать до 50k RPS на инстанс при правильной архитектуре. Потребуется ~10-15 подов.
  AI Assistant Service: инференс моделей на GPU. Один GPU может обрабатывать ~50-100 запросов в секунду (зависит от модели). Для 2400 RPS (10% от 24k) потребуется ~24-48 GPU. Используем горизонтальное масштабирование с несколькими подами, каждый с GPU.
  Cassandra: кластер из 12-20 узлов для ленты.
  PostgreSQL: мастер + несколько реплик чтения.
  Kafka: кластер из брокеров для буферизации пиковых нагрузок записи.
• Сетевые ограничения: пропускная способность каналов должна быть достаточной (например, 24k запросов * средний размер ответа 10 KB = ~240 MB/s = ~2 Gbps), плюс дополнительные расходы.

Масштабирование должно быть автоматическим, с запасом прочности (например, целевая загрузка 50% от максимума).

Дополнительные меры:

• Rate limiting на уровне Gateway для защиты от злоупотреблений.
• Circuit breaker (Hystrix / Resilience4j) для предотвращения каскадных сбоев.
• Graceful degradation: при перегрузке ИИ-сервисов возвращать пользователю заглушку или перенаправлять на упрощённую модель.

Таким образом, спроектированная система способна выдерживать заявленную нагрузку и масштабироваться дальше при необходимости.

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot
Подпишись на https://t.me/LyakhovEugene