Skip to main content

Redis Integration

Архитектурные решения по использованию Redis в GOLOOT.

1. Summary​

Goal: Определить оптимальную стратегию использования Redis для текущей инфраструктуры (1 реплика backend).

User Value: Понимание почему in-memory решения используются вместо Redis для большинства задач, и когда это нужно пересмотреть.

2. Context​

Текущая инфраструктура
  • Реплики: 1 (один контейнер backend)
  • Железо: 8GB RAM, 4 cores
  • Деплой: Dokploy, Docker Swarm
  • Пользователи админки: 1 (владелец)

Горизонтальное масштабирование не планируется в ближайшее время.

3. Current Usage​

Redis используется как cache-aside слой для горячих PG queries и для invite tracking.

Cache-Aside Layer (PG Query Cache)​

Реализован в backend/src/common/cache/cache.service.ts. Все ключи — с префиксом goloot:v1:.

ДанныеRedis KeyTTLГде кэшируетсяИнвалидация
Активный сезонgoloot:v1:season:active5 минseason.repository.tsAdmin lifecycle controller, season lifecycle job
Активные квестыgoloot:v1:quests:active:{category}2 минquest-progress.service.tsAdmin setup/quest controllers, lifecycle job
Детали кейсаgoloot:v1:case:{caseId}:details10 минcase-opening.service.tsAdmin case/reward controllers
Детали спинаgoloot:v1:spin:{spinId}:details10 минuser-spin.service.tsAdmin spin/reward controllers
Leaderboardgoloot:v1:leaderboard:{seasonId}:{limit}:{offset}2 минseason.repository.tsTTL-only (осознанный выбор)

Other Usage​

Use CaseКлючиОписание
Docs Invite Trackingdocs:invite:usage:*Отслеживание использований invite-токенов с TTL
Fastify Rate Limitplugin internalПлагин может использовать Redis, но работает in-memory

Потребление ресурсов​

RAM:  ~15-20 MB (базовый overhead + cache entries)
CPU:  ~0-1% (GET/SET операции)
Disk: ~1-5 MB (RDB snapshots)

4. ADR: Rejected Improvements​

Ниже — решения отложить внедрение Redis для различных задач.

Secure Rate Limiting → Redis Counters​

Файл: backend/src/common/middleware/secure-rate-limiting.middleware.ts

Текущая реализация: In-memory Map

Проблема​

Rate limit counters не синхронизированы между инстансами при горизонтальном масштабировании.

Решение​

Оставить in-memory Map.

Обоснование​

  1. 1 реплика — все запросы идут в один процесс, in-memory работает идеально
  2. Проблема "обхода rate limit" возникает только при 2+ репликах, когда load balancer раскидывает запросы
  3. Redis добавит latency +1-5ms на каждый запрос без реальной пользы

Когда пересмотреть​

  • При переходе на replicas: 2+
  • При использовании PM2 cluster mode
  • При развёртывании на нескольких серверах

5. Architecture Diagram​

Текущая архитектура​

6. Decision Triggers​

Когда пересмотреть решения:

СобытиеЧто пересмотреть
5,000+ DAUPG Query Cache — реализовано (Февраль 2026)
5,000+ DAUPer-user кэш (profile, user quests)
replicas: 2+ в DokployRate limiting, SSE pub/sub, User cache
Админка тормозит (> 5 сек)Analytics caching
50,000+ активных юзеровLeaderboards (Redis Sorted Sets), общая архитектура
Нужна функция "разлогинить везде"Session storage
Steam API rate limitsSteam response cache
Массовые промо-акцииPromo code race condition protection

7. Decision History​

ДатаРешениеОбоснование
Январь 2026Отказ от Redis rate limiting1 реплика, in-memory достаточно
Январь 2026Отказ от Redis pub/sub для SSE1 реплика, EventEmitter достаточно
Январь 2026Отказ от Redis analytics cache1 пользователь админки, не тормозит
Январь 2026Отказ от Redis session storeJWT stateless, работает корректно
Январь 2026Оставить Redis для docs invite10-15 MB — несущественно, готовность к росту
Февраль 2026Добавлен план PG Query CacheCapacity planning для 10K DAU выявил ~600K повторяющихся queries/день
Февраль 2026Реализован cache-aside layer5 типов данных: season, quests, cases, spins, leaderboard. Envelope pattern, graceful degradation, Prometheus metrics
  • Caching Strategy — полная инвентаризация кешей и стратегия масштабирования
  • Architecture Overview — общая архитектура системы
  • Security Matrix — матрица защит по доменам