[Feature] Реализация модуля Server-Sent Events (SSE) для Real-time обновлений #69

Контекст

Для обеспечения отзывчивости интерфейса (обновление статусов задач, уведомления о действиях команды, изменение загрузки в реальном времени) необходимо внедрить механизм Server-Sent Events. В отличие от WebSockets, SSE работает поверх стандартного HTTP, более экономичен в плане ресурсов сервера и идеально подходит для односторонней трансляции обновлений от бэкенда к клиенту (unidirectional data flow).

Технические требования

• Локация логики: src/realtime, src/shared/interceptors/sse.interceptor
• Инструменты: EventEmitters (Node.js), HTTP Streaming, Redis Pub/Sub (для горизонтального масштабирования).
• Логика работы:
  1. Создать эндпоинт GET /api/v1/events/subscribe, который удерживает HTTP-соединение с заголовками Content-Type: text/event-stream и Cache-Control: no-cache.
  2. Реализовать EventBus на базе EventEmitter для внутренней маршрутизации событий внутри сервиса.
  3. При возникновении события в системе (например, task.updated или user.status_changed), сервис должен отправлять сообщение в поток конкретного пользователя или всей команды.
  4. Реализовать механизм "Heartbeat" (отправка пустого комментария : keep-alive каждые 15-30 секунд) для предотвращения разрыва соединения прокси-серверами (NGINX/Cloudflare).

Цель и критерии приемки (Definition of Done)

• База: Создан базовый контроллер для обработки SSE-соединений.
• Функционал: Клиент получает уведомление об изменении статуса задачи в течение < 500мс после совершения действия другим пользователем.
• Лимиты/SLA: Система должна поддерживать до 5000 одновременных открытых соединений на один инстанс при минимальном потреблении CPU.
• Интеграция: Подключен Redis Pub/Sub для синхронизации событий между несколькими инстансами бэкенда.

Важные указания

• Производительность: Обязательно настроить корректное закрытие стримов при отключении клиента (req.on('close')), чтобы избежать утечек памяти (Memory Leaks).
• Ошибки: Если соединение прервано, клиент должен иметь возможность восстановить его. Использовать поле id в SSE сообщениях, чтобы клиент мог отслеживать последнее полученное событие.
• Безопасность: Проверка JWT-токена должна происходить при установке соединения. SSE-поток должен фильтровать события согласно правам доступа пользователя (интеграция с CASL), чтобы исключить утечку данных о задачах из чужих команд.