Pub/Sub (Publish/Subscribe) est le modèle de messaging de Redis où les publishers envoient des messages à des channels et les subscribers reçoivent les messages des channels auxquels ils sont abonnés — sans que les publishers et subscribers ne se connaissent mutuellement. Cela permet la messagerie en temps réel et une communication découplée entre les services.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Les publishers PUBLISH sur un channel ; les subscribers SUBSCRIBE aux channels et reçoivent les messages en temps réel. Ils sont découplés — le publisher ne sait pas qui (le cas échéant) écoute.
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
→ Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
→ If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
→ No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
→ use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
→ or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
Comprendre Redis Pub/Sub est précieux pour la messagerie en temps réel et la communication découplée, c'est donc une connaissance utile — mais de manière critique, comprendre ses limitations est tout aussi important pour l'utiliser correctement.
Pub/Sub permet la messagerie en temps réel où les publishers diffusent vers des channels et les subscribers reçoivent instantanément, avec les publishers et subscribers découplés (inconscients les uns des autres) — alimentant les cas d'usage comme les notifications en temps réel, le chat, les mises à jour de tableau de bord en direct, et la communication entre services découplée (souvent couplée avec WebSockets pour pousser les mises à jour vers les navigateurs).
Cela fait de Redis une option simple et rapide pour les fonctionnalités de diffusion en temps réel.
Cependant, le point le plus important est de comprendre la limitation fire-and-forget de Pub/Sub : c'est une livraison au plus une fois — les messages ne parviennent qu'aux subscribers connectés à ce moment, et les subscribers hors ligne manquent définitivement les messages (pas de persistance, replay, accusé de réception ou garantie de livraison).
C'est une contrainte cruciale : Pub/Sub ne convient pas quand la livraison fiable ou l'historique des messages compte, et ne pas comprendre cela conduit à des bugs de perte de messages.
Connaître les alternatives — Redis Streams (durable, basé sur des logs, avec des groupes de consumers et des accusés de réception) ou des brokers dédiés (Kafka, RabbitMQ) pour la messagerie fiable — et choisir Pub/Sub uniquement pour la simple diffusion en temps réel où les messages manqués sont acceptables reflète un bon jugement.
Puisque la messagerie en temps réel est un besoin courant, et puisque Redis Pub/Sub fournit une solution simple pour cela mais avec des limitations de fiabilité importantes (nécessitant Streams ou un broker quand des garanties sont nécessaires), comprendre Pub/Sub — comment cela fonctionne, ses cas d'usage, et surtout sa limitation fire-and-forget et quand utiliser Streams à la place — est une connaissance pratique et précieuse pour implémenter les fonctionnalités en temps réel correctement, où comprendre la limitation est tout aussi important que comprendre la capacité.