Redis : deux stores, deux promesses

Le paradoxe apparent

Le même thread_id de conversation copilot vit dans deux stores : le checkpointer LangGraph dans Postgres, et l'historique de chat dans Redis. Doublon ? Non — deux promesses différentes :

La leçon générale : la source de vérité et la projection d'affichage n'ont ni le même SLA ni le même cycle de vie — leur donner le même store, c'est imposer à l'un les contraintes de l'autre.

L'anatomie des clés Redis

conv:{tenant}:{user}:{conv}        → JSON : les messages du thread
conv:meta:{tenant}:{user}:{conv}   → JSON : {titre, nb_messages, dernière_activité}
conv:list:{tenant}:{user}          → ZSET : conv_ids scorés par timestamp (le tri de la sidebar)

Trois idées dedans :

1. l'isolation tenant/user est dans la forme de la clé — pas de RLS en Redis, la clé EST le scope ;
2. le ZSET donne la sidebar triée par activité en une commande (zrevrange) — la structure de données choisie EST la requête ;
3. TTL glissant : ré-armé à chaque écriture — un thread actif ne meurt jamais, un thread abandonné s'efface tout seul (RGPD-friendly, zéro job de purge).

La discipline single-key (cluster-ready)

Toutes les opérations sont mono-clé (set, get, zadd, zrevrange, expire…) — jamais de transaction multi-clés. C'est ce qui rend le code identique entre le Redis standalone du dev et le cluster ElastiCache 3 shards de la prod : en cluster, les clés sont réparties par slot, et une op multi-clés exige que toutes vivent sur le même nœud (hash-tags, complexité). La conséquence assumée : de petites incohérences possibles (une entrée de ZSET dont le meta a expiré) — nettoyées paresseusement à la lecture plutôt que prévenues par transaction.

Et l'invariant privacy du module 4 se prolonge ici : Redis ne persiste que les model_view des résultats de tools — les ui_events (données complètes) ne sont jamais stockés. Recharger la page ne peut pas ressusciter des données que l'utilisateur n'aurait plus le droit de voir.