feat(scale): cache cluster + WebSocket scaling (Redis Sentinel + sticky session + message broker)

[Yanstart]

Cadrage stratégique 2026 (mai 2026) — PIVOT PRODUIT

TileCache L2 + WebSocket scaling pour produit multi-tenant + N réplicas backend.
Voir `.claude/memory/VISION_ALIGNMENT.md §0.6`.

Contexte

Aujourd'hui :

• Cache : Redis single instance, port 6380. `TwoLevelTileCache` L1 mem (intra-instance) + L2 Redis (partagée).
• WebSocket : sprint 15 a livré `WorkflowEventBroadcaster` qui maintient un set d'`asyncio.Queue` dans la mémoire d'une seule instance backend. Si 2+ instances backend, les events publiés sur instance A ne sont pas reçus par les clients connectés à instance B.

Pour un produit multi-tenant avec N réplicas backend (Wave 13 #N15
Helm/Kubernetes), il faut :

1. Cache résilient (failover) — Redis Sentinel ou Cluster
2. WebSocket events propagés cross-replica — message broker (Redis pub/sub OU Kafka/NATS)
3. Sticky sessions WebSocket OU broker-based broadcast
4. Multi-tenant aware : namespace par tenant, pas de cross-talk

Cible

1. Redis Sentinel (failover automatique 1 master + N replicas) OU Redis Cluster (sharding)
2. WebSocket broadcast inter-replicas :
   • Option A : Redis pub/sub channel `workflow_events:{tenant_id}`
   • Option B : NATS / Kafka pour throughput supérieur
3. Sticky sessions côté ingress (Kubernetes) pour réduire les disconnects
4. Namespace multi-tenant : clé Redis préfixée `{tenant_id}:...`, channel WS scoped par tenant

Approche technique proposée

1. `backend/services/cache/two_level_tile_cache.py` : ajout support Redis Sentinel (auto-discovery du master)
2. `backend/services/workflow/websocket_hook.py` + `WorkflowEventBroadcaster` : refactor pour publier sur Redis pub/sub au lieu de set local. Chaque instance backend s'abonne au channel.
3. Multi-tenant : channels `workflow_events:{tenant_id}` séparés, autorization vérifiée à la connexion WS
4. `docker-compose.yml --profile prod` : Redis Sentinel ou Cluster (3 nodes minimum)
5. Tests : 2 instances backend simulées, event publié sur A → reçu sur B

Acceptance criteria

• Redis Sentinel (ou Cluster) configuré et testé
• `TwoLevelTileCache` supporte le failover Redis automatique
• WebSocket events propagés via Redis pub/sub (pas mémoire locale)
• Multi-tenant : channels Redis par tenant, isolation prouvée par tests
• Sticky sessions documentées pour ingress Kubernetes
• Tests : 2 instances backend, broadcast cross-instance OK
• Tests : kill master Redis → failover automatique < 30s
• Métriques Prometheus : hit rate L1/L2 par tenant, lag pub/sub, connections WS par instance
• Documentation runbook `docs/Admin/services/cache-ws-scaling.md`

Dépendances

• Wave 13 feat(scale): multi-tenant data isolation + auth federation #354 (multi-tenant) — namespace par tenant
• Wave 13 #N15 (Helm/GitOps) — sticky session ingress configuration
• Sprint 15 livré (WebSocketWorkflowHook) — base à refactor

Références

• `.claude/memory/VISION_ALIGNMENT.md §0.6`
• Existing : `backend/services/cache/two_level_tile_cache.py`, `backend/services/workflow/websocket_hook.py`
• Redis Sentinel : https://redis.io/docs/management/sentinel/
• Redis pub/sub : https://redis.io/docs/manual/pubsub/