Plan MVP 3

Этап 3: масштабирование

Цель: платформа выдерживает устойчивую нагрузку и растёт управляемо. Ничего из этой страницы ещё не реализовано. Статусы: Дорожная карта.

Простой пример

Менеджмент хочет знать, какая доля просмотров тура заканчивается заявкой. Фронтенд и сервисы отправляют события «просмотр тура» и «создание заявки», сервис аналитики складывает их в ClickHouse, а GET /api/v1/analytics/funnel возвращает воронку по дням: 1000 просмотров, 40 заявок, 12 подтверждений.

Объём

• Отдельный analytics-service: хранение и агрегация событий, показатели, воронки, отчёты.
• Отчёты для менеджмента: панели, выгрузки (Excel и аналогичные).
• Подготовка к нескольким экземплярам сервисов и автомасштабированию, Kubernetes при подтверждённой необходимости.
• Устойчивость к частичным отказам.

Компоненты

Компонент	Зачем
analytics-service	ClickHouse или Timescale, показатели, воронки, отчёты
Kubernetes	развёртывание при подтверждённой необходимости масштабирования
Prometheus, Grafana, хранилище трассировок	расширенная наблюдаемость

Фронтенд и Gateway: REST и realtime (чат, уведомления). Между сервисами: gRPC и шина событий. Аналитика читает события из шины и outbox сервисов.

Домен и данные

• Факты: FactUserEvent, FactBookingEvent. Измерения: DimTour, DimUser, DimManager.
• Срок хранения по типам событий, псевдонимизация персональных данных, версии схемы событий.
• Контроль пропусков при загрузке, дедупликация по ключу события.

API

Только для ролей Manager и Admin:

• GET /api/v1/analytics/kpi
• GET /api/v1/analytics/funnel
• GET /api/v1/analytics/export

События для аналитики: регистрация, просмотр тура, создание и изменение заявки, отправка предложения. Существующие сценарии /api/v1 не ломаются.

Безопасность и надёжность

• Политики хранения и ротации секретов (базы, брокер, внешние API). Базовое правило уже действует: Секреты.
• Аудит и контроль доступа к аналитическим данным.
• Разделение окружений и учётных записей prod, stage, dev.
• SLO и SLI по ключевым сервисам, учения по отказам, план аварийного восстановления с RPO и RTO.

Эксплуатация

• Kubernetes и Horizontal Pod Autoscaler для нагруженных сервисов.
• Централизованный мониторинг и алерты по SLO.
• Canary или blue-green релизы.
• Инструкции для типовых инцидентов, нагрузочные тесты, планирование мощностей.

Приёмка

• Показатели и воронка конверсии считаются правильно.
• Выгрузка отчётов работает на целевых объёмах без таймаутов.
• Выполняются заявленные SLO, сервисы выдерживают нагрузочные тесты.
• Сценарий аварийного восстановления проверен и описан.