Kepiye cara Redis Pub/Sub makarya?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) yaiku pola pesen Redis nalika **publishers** ngirim pesen menyang **channels** lan **subscribers** nampa pesen saka channels sing wis ditilan — tanpa publishers lan subscribers ngerti siji-sijine. Iki ndadosake pesen real-time lan komunikasi sing ora kaitan antarane layanan.

## 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` menyang sawijining channel; subscribers `SUBSCRIBE` menyang channels lan nampa pesen kanthi real-time. Padha **ora kaitan** — publisher ora ngerti sapa (yen ana) sing krungu.

## 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)
```

## Keterbatasan 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.
```

## Yen sampeyan butuh kaandalan: gunakake 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 iki penting

Pamahaman babagan Redis Pub/Sub iku berharga kanggo **pesen real-time lan komunikasi sing ora kaitan**, dadi iku idhé paham sing migunani — nanging kritikal banget, pamahaman babagan keterbatasane padha pentinge kanggo nggunakaké kanthi tepat.

Pub/Sub ndadosake **pesen real-time** nalika publishers broadcast menyang channels lan subscribers nampa kanthi instan, lan publishers lan subscribers **ora kaitan** (ora ngerti siji-sijine) — ndadosake use cases kaya real-time notifications, chat, live dashboard updates, lan komunikasi layanan sing ora kaitan (asring dipasang karo WebSockets kanggo push updates menyang browsers).

Iki ngadhaké Redis dadi opsi sing sederhana lan cepet kanggo fitur real-time broadcast.

Nanging, poin **paling penting** yaiku pamahaman babagan keterbatasan **fire-and-forget** Pub/Sub: iki yaiku at-most-once delivery — pesen mung tekan subscribers sing koneksi ing wektu iku, lan subscribers sing offline **permanen kehilangan pesen** (tanpa persistence, replay, acknowledgment, utawa delivery guarantee).

Iki yaiku constraint sing krusial: Pub/Sub ora cocok yen reliable delivery utawa message history iku penting, lan ora ngerti iki ndadosake lost-message bugs.

Ngerti alternatif — **Redis Streams** (tahan lama, berbasis log, karo consumer groups lan acknowledgments) utawa brokers khusus (Kafka, RabbitMQ) kanggo pesen sing andal — lan milih Pub/Sub mung kanggo simple real-time broadcast nalika kehilangan pesen iku bisa ditampa nunjukake penilaian sing apik.

Sajak pesen real-time yaiku kebutuhan sing umum, lan Redis Pub/Sub nyedhiyakake solusi sing sederhana nanging karo keterbatasan kaandalan penting (merlokake Streams utawa broker yen jaminan dibutuhake), pamahaman babagan Pub/Sub — kepiye makarya, use cases-ne, lan utamane keterbatasan fire-and-forget lan kapan nggunakake Streams tinimbang — yaiku pengetahuan sing berharga lan praktis kanggo implementasi fitur real-time kanthi bener, nalika pamahaman keterbatasan iku sama pentinge karo pamahaman kapabilitas-ne.