Plan MVP 2

Этап 2: расширение

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

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

Клиент оставил заявку. Booking записал BookingCreated в outbox, обработчик отправил событие в RabbitMQ. Сервис уведомлений получил событие и отправил менеджеру письмо «Новая заявка на тур …». Если сервис уведомлений получит то же событие повторно, второго письма не будет: обработка идемпотентна по id события.

Объём

• Уведомления: письмо по событиям заявки (первым письмо менеджеру, #147), уведомления внутри сайта, базовые web push.
• Агрегация туров: сервис Supplier, поиск и карточка предложения оператора, заявка на предложение оператора, управление источниками и наценкой (эпики #118 ... #123, решение #124). Пример для сравнения: Tourvisor.
• Поиск: расширенные фильтры каталога через Elasticsearch, текстовый поиск (#74).
• Панель менеджера: больше показателей и фильтров.
• Профили и чаты: эпики #92 и #91.

Вне объёма

Хранилище данных для аналитики, Kubernetes и автомасштабирование как обязательная часть.

Компоненты

Компонент	Зачем
notification-service	email, уведомления на сайте, web push
RabbitMQ и MassTransit	доставка доменных событий между сервисами
Elasticsearch	поиск по каталогу

Синхронные запросы по-прежнему идут по gRPC.

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

• Новая сущность Notification: NotificationId, UserId, Type, Payload, IsRead, CreatedAt.
• События Booking становятся официальным контрактом интеграции и публикуются в RabbitMQ.
• Каталог получает проекцию в поисковый индекс.
• Между Booking, Chat и уведомлениями согласованность в конечном счёте; обработчики событий идемпотентны по ключу события.

API

Внешний API остаётся совместимым с /api/v1. Новые адреса (предварительно):

• GET /api/v1/notifications
• PATCH /api/v1/notifications/{id}/read
• GET /api/v1/catalog/tours?search=...

События: BookingCreated, BookingStatusChanged, ProposalSent, ChatMessageSent.

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

• Доверенный транспорт для брокера, раздельные права отправителей и получателей по очередям.
• Срок хранения и маскирование персональных данных в содержимом уведомлений.
• Очередь недоставленных сообщений (DLQ), повторы с нарастающей паузой.
• Мониторинг отставания очередей и числа повторов.

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

• RabbitMQ и Elasticsearch в окружениях этапа.
• Алерты: рост DLQ, рост задержки поиска, отставание обработчиков.
• Уведомления включаются по каналам: сначала email, потом на сайте; флаги для новых каналов.
• Индекс Elasticsearch прогревается до переключения поиска с SQL.

Приёмка

• Уведомления приходят при создании заявки, смене статуса, отправке предложения.
• Поиск по каталогу работает на новом индексе.
• Менеджер видит расширенные показатели без ухудшения интерфейса.
• Сообщения правильно маршрутизируются через RabbitMQ, повторная обработка не создаёт дублей.
• Есть наблюдаемость по очередям и ошибкам обработчиков.