[Feature] Интеграция слоя кэширования на базе Redis

[soorq]

Контекст

С ростом объема данных (задачи, доски, логи активности) и увеличением сложности запросов (агрегация Story Points, проверка прав через CASL), нагрузка на основную базу данных PostgreSQL возрастает. Внедрение распределенного кэширования необходимо для снижения задержек (latency) при чтении часто запрашиваемых данных, таких как профили пользователей, настройки досок и текущие сессии SSE.

---

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

• Локация логики: src/shared/cache, src/modules/tasks/interceptors, infrastructure/redis
• Инструменты: Redis, ioredis или node-cache-manager.
• Логика работы:
  1. Реализовать CacheService — обертку над Redis для операций get, set, del и flush.
  2. Внедрить паттерн Cache Aside:
     • При запросе данных проверяется кэш.
     • При промахе (cache miss) данные берутся из БД и записываются в кэш.
  3. Реализовать автоматическую инвалидацию: при любом UPDATE или DELETE запросе связанный ключ в Redis должен удаляться.
  4. Настроить глобальный префикс для ключей (например, tracker_cache:) и стандартный TTL (Time To Live).

---

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

• База: Поднят инстанс Redis в Docker/K8s; настроено подключение через переменные окружения.
• Функционал: Кэширование применено к эндпоинтам GET /boards и GET /users/me.
• Функционал: Реализованы декораторы для методов контроллеров, позволяющие кэшировать ответы одной аннотацией.
• Лимиты/SLA: Время ответа для закэшированных данных должно составлять < 15мс.
• Интеграция: Логирование событий кэширования (hit/miss) интегрировано в Grafana для мониторинга эффективности (Cache Hit Ratio).

---

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

• Производительность: Использовать сериализацию в JSON для хранения объектов. Для списков задач рассмотреть использование Redis Hashes или Sets при необходимости сложной выборки.
• Ошибки: Реализовать стратегию Fail-soft — если Redis недоступен, приложение должно продолжать работу, обращаясь напрямую к PostgreSQL, не выдавая ошибку пользователю.
• Безопасность: Кэшированные данные не должны содержать конфиденциальную информацию в открытом виде, если доступ к Redis не ограничен. Учитывать права доступа: кэш должен быть разделен по user_id или role, чтобы избежать ситуации, когда пользователь видит данные чужой доски из кэша.