Jobs e Cache · infrastructure/cache
Adapter pronto para produçãoRedis,
opcional mas pronto.
O Redis é o substrato compartilhado de três subsistemas aqui — caching, jobs em background e rate limiting. Ele é opcional em dev: o cache cai para um store em memória, então um clone novo roda sem nada externo, e escala horizontalmente no momento em que você seta REDIS_URL.
Fallback gracioso por design
A factory de cache retorna um store apoiado no Redis quando REDIS_URL está presente e um LRU em memória caso contrário. Dev e prod de instância única funcionam sem Redis; deployments multi-instância setam REDIS_URL e ganham um cache distribuído sem mudar código.
1 export const createCacheStore = ({ redisUrl, logger }) => {
2 if (!redisUrl) {
3 return new InMemoryCacheStore();
4 }
5 const redis = new Redis(redisUrl, { lazyConnect: true });
6 return new RedisCacheStore(redis);
7 };
Três subsistemas, uma dependência
Cache
Store Redis quando REDIS_URL está setada, LRU em memória caso contrário — seguro para instância única, obrigatório para multi-instância.
Jobs
Os workers e filas do BullMQ se conectam por uma conexão ioredis dedicada com a peculiaridade de null-retry resolvida.
Rate limiting
Cada tier do limiter (read / write / auth-ip / auth-email) tem seu próprio store Redis com um prefixo de key único, então os contadores nunca colidem.
Sobe sem nada
Adapters opcionais fazem no-op ou caem em fallback quando não setados — o boilerplate sempre sobe com o env mínimo obrigatório.
Referência de configuração
Variáveis de ambiente
REDIS_URLopcionalunset → in-memory cache; required for jobs & distributed cache
JOBS_REDIS_URLopcionaloptional dedicated Redis for BullMQ
Onde ele vive
apps/server/src/infrastructure/cache/factory.tsapps/server/src/infrastructure/jobs/redis-connection.ts
Cache e filas que escalam quando você escala.
Rode sem nada externo em dev; sete uma URL para ir distribuído em prod.