Apakah LISTEN dan NOTIFY?

Question

Accepted Answer

**`LISTEN`** dan **`NOTIFY`** menyediakan sistem pemesejan **publish/subscribe** terbina dalam PostgreSQL — satu sesi boleh menghantar notifikasi pada satu channel, dan sesi lain yang mendengar pada channel itu menerimanya serta-merta. Ia merupakan cara ringan untuk menolak event masa nyata daripada pangkalan data tanpa polling.

## Mekanisme asas

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN melanggan sesuatu channel; NOTIFY menerbitkan kepadanya (dengan payload teks pilihan). Pendengar diberitahu secara asynchronous — tiada polling diperlukan.

## Mencetuskan NOTIFY secara automatik (corak biasa)

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

Menggabungkan NOTIFY dengan **trigger** membolehkan pangkalan data menolak event secara automatik apabila data berubah (order baharu, kemas kini status) — pelayan aplikasi yang mendengar pada channel bertindak balas dalam masa nyata.

## Bagaimana aplikasi menggunakannya

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## Batasan yang perlu diketahui

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## Mengapa ia penting

`LISTEN`/`NOTIFY` ialah ciri PostgreSQL yang berguna dan agak kurang dikenali yang menyediakan **pemesejan pub/sub terbina dalam**, berharga untuk menambah **kereaktifan masa nyata** kepada aplikasi tanpa polling.

Nilai terasnya ialah membolehkan pangkalan data **menolak event** kepada sesi aplikasi yang mendengar serta-merta apabila sesuatu berlaku (order baharu, perubahan status) — biasanya digabungkan dengan **trigger** supaya perubahan data secara automatik memberitahu pendengar, yang ditindak balas oleh pelayan aplikasi (menolak ke websocket, membatalkan cache, mencetuskan kerja latar belakang).

Ini berharga kerana ia menyediakan tingkah laku berpacukan-event masa nyata tanpa ketidakcekapan **polling** pangkalan data berulang kali untuk memeriksa perubahan (corak biasa yang membazir yang digantikan dengan elegan oleh LISTEN/NOTIFY).

Memahami mekanisme (LISTEN untuk melanggan, NOTIFY untuk menerbitkan, dengan trigger untuk notifikasi automatik pada perubahan data) dan bagaimana aplikasi menggunakannya (mendengar event untuk memacu tindak balas masa nyata) adalah berguna untuk membina aplikasi berpacukan-event yang responsif menggunakan PostgreSQL sahaja.

Sama pentingnya ialah mengetahui **batasan**: notifikasi **tidak dikekalkan (not persisted)** (hilang jika tiada sesiapa mendengar — tiada jaminan ketahanan), mempunyai payload yang kecil, dan hanya dicetuskan selepas commit — jadi ia sesuai untuk isyarat masa nyata yang ringan, *bukan* pengganti untuk message broker yang tahan lama (RabbitMQ, Kafka) apabila kebolehpercayaan dan kekekalan penting.

Memandangkan kereaktifan masa nyata merupakan keperluan biasa dan LISTEN/NOTIFY menawarkan cara terbina dalam, tanpa polling untuk mencapainya bagi kes ringan, memahaminya — mekanisme pub/sub, corak trigger, dan yang penting batasannya (bila ia memadai berbanding bila broker sebenar diperlukan) — ialah pengetahuan PostgreSQL yang berharga dan relevan secara praktikal untuk membina aplikasi berpacukan-event, satu ciri terbina dalam yang berguna yang sering terlepas pandang.