Pub/Sub (Publish/Subscribe) એ Redis નું મેસેજિંગ પેટર્ન છે જ્યાં publishers ચેનલો માટે મેસેજ મોકલે છે અને subscribers તેઓ સબ્સ્ક્રાઇબ કરેલી ચેનલોમાંથી મેસેજ પ્રાપ્ત કરે છે — પ્રકાશકો અને ગ્રાહકો એક બીજા વિશે જાણતા નથી. તે વાસ્તવિક સમયનું મેસેજિંગ અને સેવાઓ વચ્ચે અલગ સંચાર સક્ષમ કરે છે.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
પ્રકાશકો PUBLISH ને ચેનલમાં મોકલે છે; subscribers SUBSCRIBE ને ચેનલોમાં કરે છે અને વાસ્તવિક સમયે મેસેજ પ્રાપ્ત કરે છે. તેઓ અલગ છે — પ્રકાશક જાણતો નથી કે કોણ (જો કોઈ હોય તો) સાંભળી રહ્યો છે.
✓ 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 સમજવું વાસ્તવિક સમયનું મેસેજિંગ અને અલગ સંચાર માટે મૂલ્યવાન છે, તેથી તે ઉપયોગી જ્ઞાન છે — પરંતુ જટિલ રીતે, તેની મર્યાદાઓ સમજવું તેનો સંજોગોમાં યોગ્ય રીતે ઉપયોગ કરવા માટે સમાન મહત્વપૂર્ણ છે.
Pub/Sub વાસ્તવિક સમયનું મેસેજિંગ સક્ષમ કરે છે જ્યાં publishers ચેનલોમાં પ્રસારણ કરે છે અને subscribers તરત જ પ્રાપ્ત કરે છે, publishers અને subscribers અલગ (એક બીજાથી અજાણ) — વાસ્તવિક સમયનાં સૂચનાઓ, ચેટ, જીવંત ડેશબોર્ડ અપડેટ્સ અને અલગ સેવા સંચાર (ઘણીવાર WebSockets સાથે પેર કરીને બ્રાઉજર્સમાં અપડેટ્સ દબાણ કરવા) જેવા ઉપયોગ કેસોને શક્તિ આપતું.
તે Redis ને વાસ્તવિક સમયની પ્રસારણ સુવિધાઓ માટે એક સરળ, ઝડપી વિકલ્પ બનાવે છે.
તેમ છતાં, સૌથી મહત્વપૂર્ણ બિંદુ Pub/Sub ની fire-and-forget મર્યાદા સમજવું છે: તે સર્વોચ્ચ-એક વાર ડિલિવરી છે — મેસેજ તે ક્ષણે જોડાયેલા subscribers સુધી પહોંચે છે, અને ઓફલાઇન subscribers કાયમે મેસેજો મિસ કરે છે (કોઈ સતત રહેણાક, રીપ્લે, સ્વીકૃતિ અથવા ડિલિવરી ગ્યારંટી નથી).
યह એક નિર્ણાયક મર્યાદા છે: જ્યારે વિશ્વસનીય ડિલિવરી અથવા મેસેજ ઇતિહાસ મહત્વપૂર્ણ હોય ત્યારે Pub/Sub અયોગ્ય છે, અને આને સમજતો નથી તે lost-message બગ્સ તરફ દોરી જાય છે.
વિકલ્પોને જાણવું — Redis Streams (ટકાઉ, log-આધારિત, ઉપભોક્તા જૂથો અને સ્વીકૃતિઓ સાથે) અથવા વિશ્વસનીય મેસેજિંગ માટે સમર્પિત બ્રોકર્સ (Kafka, RabbitMQ) — અને Pub/Sub માત્ર સરળ વાસ્તવિક સમયની પ્રસારણ માટે પસંદ કરવું જ્યાં મેસેજો મિસ કરવું સ્વીકાર્ય હોય તે સાયમાન બુદ્ધિમત્તા પ્રતિબિંબિત કરે છે.
વાસ્તવિક સમયનું મેસેજિંગ એક સામાન્ય જરૂરિયાત છે, અને Redis Pub/Sub તેના માટે એક સરળ સમાધાન આપે છે પરંતુ મહત્વપૂર્ણ વિશ્વસનીયતા મર્યાદાઓ સાથે (જ્યારે ગ્યારંટીઓ જરૂરી હોય ત્યારે Streams અથવા બ્રોકરની જરૂર હોય છે), Pub/Sub સમજવું — તે કેવી રીતે કાર્ય કરે છે, તેના ઉપયોગ કેસો, અને ખાસ કરીને તેની fire-and-forget મર્યાદા અને Streams ના બદલે ક્યારે ઉપયોગ કરવું — વાસ્તવિક સમયની સુવિધાઓ સાચી રીતે અમલમાં મૂકવા માટે મૂલ્યવાન, વ્યવહારિક રીતે સંબંધિત જ્ઞાન છે, જ્યાં મર્યાદાને સમજવું ક્ષમતા સમજવા જેટલું જ મહત્વપૂર્ણ છે.