Notifications temps réel à l’échelle avec Redis Pub/Sub et Socket.IO
Comment Redis Pub/Sub et l’adaptateur Redis de Socket.IO permettent de faire évoluer les notifications WebSocket sur plusieurs serveurs Node.js.
Les notifications temps réel sont simples sur un seul serveur. Une connexion WebSocket reste attachée à un processus, et dès qu’un événement se produit, ce processus peut pousser le message directement au client.
L’architecture change lorsque le trafic grandit et que plusieurs instances Node.js sont placées derrière un load balancer. Si un utilisateur est connecté au Serveur 1 et un autre au Serveur 2, une notification produite sur le Serveur 1 ne peut pas atteindre le second utilisateur tant que les serveurs ne partagent pas d’état.
Redis Pub/Sub est le backplane standard pour résoudre ce problème. Chaque instance Node.js maintient une connexion ouverte vers Redis, et lorsqu’un serveur doit diffuser une notification, il publie l’événement dans un canal au lieu de supposer que tous les destinataires sont connectés localement.
Tous les autres serveurs sont abonnés au même canal. Quand le Serveur 2 reçoit l’événement publié, il peut vérifier ses sockets locaux et distribuer la notification aux utilisateurs concernés connectés à cette instance.
L’adaptateur officiel @socket.io/redis-adapter abstrait la majorité de cette coordination. Cela permet de passer d’un serveur à plusieurs sans réécrire la logique principale des notifications à chaque montée en charge.
La leçon plus large est architecturale : les systèmes temps réel ne passent pas à l’échelle avec les WebSockets seuls. Ils passent à l’échelle lorsque la gestion des connexions, la distribution des événements et l’infrastructure horizontale sont pensées ensemble.