Données Redis

Redis 7.4 sert au backend pour quatre usages : les files de jobs BullMQ, l'état court (codes à usage unique, verrous, sessions révoquées, idempotence), quelques données utilisateur sans table en base, et le relais d'événements Socket.IO. Ce fonctionnement découle d'une décision d'architecture prise le 10 novembre 2026 : une seule instance Redis, toutes les clés applicatives préfixées par environnement, un délai de commande court et un repli en mémoire si Redis est indisponible. Les choix techniques d'ensemble sont présentés sur la page Choix techniques.

Tout accès passe par backend/src/config/redis.config.ts, qui exporte le singleton redis (classe RedisManager), sauf trois usages qui prennent le client brut redis.getRawClient() : BullMQ, le limiteur de débit et le relais Socket.IO.

#Client et préfixe

Le client ioredis est créé ainsi, sauf quand NODE_ENV vaut test (aucun client dans ce cas) :

Les méthodes get, set, setIfAbsent et del de RedisManager préfixent automatiquement chaque clé :

<REDIS_KEY_PREFIX>:<NODE_ENV>:<clé>

Avec les valeurs par défaut, la clé chain:keeper-lock devient blocklucky:development:chain:keeper-lock en développement et blocklucky:production:chain:keeper-lock en Docker Compose. Les tableaux ci-dessous donnent les clés sans ce préfixe.

Chaque commande a un délai de 500 ms (CACHE_COMMAND_TIMEOUT_MS). del utilise UNLINK, qui libère la mémoire en arrière-plan.

#Gigue des durées de vie

set(clé, valeur, ttl) applique une gigue de plus ou moins 10 % à la durée de vie (withJitter) : une clé de 600 s expire entre 540 et 660 s. Cela évite que des milliers de clés créées au même instant expirent au même instant. setIfAbsent n'applique pas de gigue : les verrous gardent une durée exacte.

Les données dont la durée est critique portent leur propre échéance : le défi OTP stocke expiresAt dans sa valeur, et la révocation de session prend une marge de 20 % plus 30 s.

#Clés applicatives

#Authentification et sessions

#Requêtes et webhooks

#Blockchain

#Données utilisateur et partenaires

Ces clés n'ont pas de durée de vie et n'ont pas d'équivalent en base. Elles sont donc des données persistantes, sauvegardées seulement par la persistance AOF de Redis.

L'ancienne clé user:ticket_limit:<userId>, qui portait le plafond personnel de jeu responsable, n'est plus ni écrite ni lue depuis le retrait de PUT /user/responsible-limit : avec un ticket par participant, le profil renvoie toujours maxTicketsPerRound: 1. Les valeurs déjà présentes dans une instance Redis existante restent sans effet et peuvent être supprimées (SCAN sur le motif *:user:ticket_limit:*, puis DEL).

#Clés hors RedisManager

Le limiteur de débit est défini dans backend/src/middlewares/rateLimiter.middleware.ts avec le magasin rate-limit-redis. Il est réglé en passOnStoreError: true : si Redis ne répond pas, la requête passe (choix fail-open, pour que la panne de Redis n'arrête pas l'API).

#Files BullMQ

Trois files partagent les options de backend/src/queues/queue.options.ts : 5 tentatives, attente exponentielle à partir de 1 s avec gigue de 50 %, jobs terminés conservés 24 h (1 000 au plus), jobs en échec conservés 14 jours.

Les files ne passent pas par RedisManager : leurs clés ne portent pas le préfixe REDIS_KEY_PREFIX, mais le préfixe par défaut de BullMQ, bull. Par exemple bull:chain-actions:wait, bull:chain-actions:failed, bull:ledger-queue:<jobId>. Deux environnements qui partageraient une même instance Redis partageraient donc leurs files.

La file chain-actions est détaillée sur la page File d'actions on-chain, les deux autres sur la page Files et workers.

#Repli en mémoire

Chaque méthode de RedisManager teste d'abord si le client est prêt (status === 'ready'). S'il ne l'est pas, ou si la commande échoue ou dépasse 500 ms, elle utilise une Map locale au process :

Le repli permet à l'API de continuer à servir quand Redis tombe. Ses limites :

• la Map est propre à chaque process : les verrous (chain:keeper-lock, wallet:grant-lock) et l'idempotence ne protègent plus entre l'API et le worker ou entre plusieurs instances ;
• les données écrites pendant la panne ne sont pas recopiées dans Redis au retour, et réciproquement : une clé écrite en mémoire n'est plus lue une fois Redis revenu ;
• la Map n'a pas de limite de taille et est perdue au redémarrage.

Pour les files, le repli consiste à exécuter le travail directement dans le process (envoi d'email, opération ledger, action on-chain), sans réessai. Sans client Redis du tout, le process worker refuse de démarrer (« Aucun worker démarré : Redis est requis pour le process worker »).

Dans les tests unitaires, redis.config est remplacé par backend/__tests__/__mocks__/redis.mock.ts, une Map sans durée de vie dont getRawClient() renvoie null.

#Configuration du serveur Redis

Le service redis de docker-compose.yml lance redis:7.4-alpine avec :

Les données sont dans le volume redisdata. Le port n'est publié que sur 127.0.0.1:6380.

#Inspecter les clés

docker compose exec redis redis-cli --scan --pattern 'blocklucky:production:*'
docker compose exec redis redis-cli TTL blocklucky:production:chain:keeper-lock
docker compose exec redis redis-cli --scan --pattern 'bull:chain-actions:*'

--scan parcourt les clés par lots, sans bloquer le serveur comme le ferait KEYS.