Pub/Sub (Publish/Subscribe) ni mfumo wa ujumbe wa Redis ambapo publishers hutuma ujumbe kwa channels na subscribers hupokea ujumbe kutoka channels walizojiandikisha — bila publishers na subscribers kujua kuhusu wao kwa wao. Huwezesha ujumbe wa wakati halisi na mawasiliano yaliyotenganishwa kati ya services.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Publishers PUBLISH kwa channel; subscribers SUBSCRIBE kwa channels na hupokea ujumbe kwa wakati halisi. Wametenganishwa — publisher hajui ni nani (kama yupo) anayesikiliza.
✓ 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
Kuelewa Redis Pub/Sub ni yenye thamani kwa ujumbe wa wakati halisi na mawasiliano yaliyotenganishwa, hivyo ni maarifa muhimu — lakini kwa umuhimu, kuelewa vikomo vyake ni muhimu vile vile ili kuitumia ipasavyo.
Pub/Sub huwezesha ujumbe wa wakati halisi ambapo publishers hutangaza kwa channels na subscribers hupokea papo hapo, na publishers na subscribers wametenganishwa (hawajui wao kwa wao) — ikiendesha matumizi kama notifications za wakati halisi, chat, live dashboard updates, na mawasiliano yaliyotenganishwa ya service (mara nyingi yanayooanishwa na WebSockets kusukuma updates kwa browsers).
Hii hufanya Redis kuwa chaguo rahisi, la haraka kwa vipengele vya broadcast vya wakati halisi.
Hata hivyo, jambo muhimu zaidi ni kuelewa kikomo cha fire-and-forget cha Pub/Sub: ni at-most-once delivery — ujumbe hufika tu kwa subscribers waliounganishwa wakati huo, na subscribers walio offline hukosa ujumbe milele (hakuna persistence, replay, acknowledgment, au dhamana ya delivery).
Hiki ni kizuizi muhimu: Pub/Sub haifai wakati delivery ya kuaminika au historia ya ujumbe ni muhimu, na kutoelewa hili husababisha hitilafu za ujumbe uliopotea.
Kujua mbadala — Redis Streams (ya kudumu, inayotegemea log, yenye consumer groups na acknowledgments) au brokers maalum (Kafka, RabbitMQ) kwa ujumbe wa kuaminika — na kuchagua Pub/Sub tu kwa broadcast rahisi ya wakati halisi ambapo kukosa ujumbe kunakubalika kunaakisi hukumu sahihi.
Kwa kuwa ujumbe wa wakati halisi ni hitaji la kawaida, na kwa kuwa Redis Pub/Sub hutoa suluhisho rahisi kwa hilo lakini lenye vikomo muhimu vya uaminifu (likihitaji Streams au broker wakati dhamana zinahitajika), kuelewa Pub/Sub — jinsi inavyofanya kazi, matumizi yake, na hasa kikomo chake cha fire-and-forget na wakati wa kutumia Streams badala yake — ni maarifa yenye thamani, yanayohusiana na vitendo kwa kutekeleza vipengele vya wakati halisi kwa usahihi, ambapo kuelewa kikomo ni muhimu kama kuelewa uwezo.