Pub/Sub (Publish/Subscribe) Redis का messaging pattern है जहाँ publishers channels को messages भेजते हैं और subscribers उन channels से messages प्राप्त करते हैं जिनकी उन्होंने subscribe किया है — बिना publishers और subscribers के एक-दूसरे के बारे में जाने। यह real-time messaging और services के बीच decoupled communication को संभव बनाता है।
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Publishers एक channel को PUBLISH करते हैं; subscribers channels को SUBSCRIBE करते हैं और real time में messages प्राप्त करते हैं। ये decoupled हैं — publisher को नहीं पता कि कौन (यदि कोई) सुन रहा है।
✓ 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
Redis Pub/Sub को समझना real-time messaging और decoupled communication के लिए मूल्यवान है, इसलिए यह उपयोगी ज्ञान है — लेकिन महत्वपूर्ण रूप से, इसका उचित उपयोग करने के लिए इसकी सीमाओं को समझना भी उतना ही महत्वपूर्ण है।
Pub/Sub real-time messaging को संभव बनाता है जहाँ publishers channels को broadcast करते हैं और subscribers तुरंत प्राप्त करते हैं, publishers और subscribers के decoupled (एक-दूसरे से अनजान) होने के साथ — real-time notifications, chat, live dashboard updates, और decoupled service communication (अक्सर browsers को updates push करने के लिए WebSockets के साथ जोड़ा गया) जैसे use cases को संचालित करता है।
यह Redis को real-time broadcast features के लिए एक सरल, तेज़ विकल्प बनाता है।
हालाँकि, सबसे महत्वपूर्ण बिंदु Pub/Sub की fire-and-forget सीमा को समझना है: यह at-most-once delivery है — messages केवल उस समय connected subscribers तक पहुँचते हैं, और offline subscribers स्थायी रूप से messages चूक जाते हैं (कोई persistence, replay, acknowledgment, या delivery guarantee नहीं)।
यह एक महत्वपूर्ण बाधा है: Pub/Sub तब अनुपयुक्त है जब reliable delivery या message history मायने रखता है, और इसे न समझना lost-message bugs की ओर ले जाता है।
विकल्पों को जानना — reliable messaging के लिए Redis Streams (durable, log-आधारित, consumer groups और acknowledgments के साथ) या dedicated brokers (Kafka, RabbitMQ) — और Pub/Sub को केवल साधारण real-time broadcast के लिए चुनना जहाँ messages चूकना स्वीकार्य है, ठोस निर्णय को दर्शाता है।
चूँकि real-time messaging एक सामान्य ज़रूरत है, और चूँकि Redis Pub/Sub इसके लिए एक सरल समाधान प्रदान करता है लेकिन महत्वपूर्ण reliability सीमाओं के साथ (guarantees की ज़रूरत होने पर Streams या एक broker की आवश्यकता), इसलिए Pub/Sub को समझना — यह कैसे काम करता है, इसके use cases, और विशेष रूप से इसकी fire-and-forget सीमा और कब इसके बजाय Streams का उपयोग करना है — real-time features को सही ढंग से लागू करने के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है, जहाँ सीमा को समझना क्षमता को समझने जितना ही महत्वपूर्ण है।