Bagaimana cara kerja Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) adalah pola messaging Redis di mana **publishers** mengirim pesan ke **channels** dan **subscribers** menerima pesan dari channels yang mereka subscribe — tanpa publishers dan subscribers saling mengenal satu sama lain. Ini memungkinkan messaging real-time dan komunikasi yang decoupled antar services.

## Model Pub/Sub

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publishers `PUBLISH` ke channel; subscribers `SUBSCRIBE` ke channels dan menerima pesan secara real-time. Mereka **decoupled** — publisher tidak tahu siapa (jika ada) yang mendengarkan.

## Use cases

```text
✓ 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)
```

## Batasan penting: fire-and-forget

```text
⚠️ 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.
```

## Ketika Anda membutuhkan reliability: gunakan Streams

```text
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
```

## Mengapa ini penting

Memahami Redis Pub/Sub bernilai untuk **real-time messaging dan komunikasi yang decoupled**, sehingga pengetahuan ini berguna — tetapi secara kritis, memahami batasannya sama pentingnya untuk menggunakannya dengan tepat.

Pub/Sub memungkinkan **real-time messaging** di mana publishers broadcast ke channels dan subscribers menerima secara instan, dengan publishers dan subscribers **decoupled** (tidak saling mengenal) — mendukung use cases seperti real-time notifications, chat, live dashboard updates, dan komunikasi service yang decoupled (sering dikombinasikan dengan WebSockets untuk push updates ke browsers).

Ini membuat Redis menjadi pilihan yang sederhana dan cepat untuk fitur broadcast real-time.

Namun, **poin paling penting** adalah memahami batasan **fire-and-forget** dari Pub/Sub: delivery at-most-once — pesan hanya sampai ke subscribers yang terhubung saat itu, dan subscribers offline **selamanya kehilangan pesan** (tidak ada persistence, replay, acknowledgment, atau delivery guarantee).

Ini adalah batasan krusial: Pub/Sub tidak cocok ketika reliable delivery atau message history penting, dan tidak memahami hal ini menghasilkan bugs kehilangan pesan.

Mengetahui alternatifnya — **Redis Streams** (durable, berbasis log, dengan consumer groups dan acknowledgments) atau dedicated brokers (Kafka, RabbitMQ) untuk reliable messaging — dan memilih Pub/Sub hanya untuk simple real-time broadcast di mana kehilangan pesan dapat diterima mencerminkan pertimbangan yang baik.

Karena real-time messaging adalah kebutuhan umum, dan karena Redis Pub/Sub menyediakan solusi sederhana untuk itu tetapi dengan batasan reliability penting (membutuhkan Streams atau broker ketika guarantees diperlukan), memahami Pub/Sub — cara kerjanya, use cases-nya, dan khususnya batasan fire-and-forget-nya dan kapan menggunakan Streams sebagai gantinya — adalah pengetahuan yang bernilai dan praktis-relevan untuk mengimplementasikan fitur real-time dengan benar, di mana memahami batasan sama pentingnya dengan memahami kemampuannya.