LISTEN และ NOTIFY คืออะไร?

Question

Accepted Answer

**`LISTEN`** และ **`NOTIFY`** ให้ระบบ messaging แบบ **publish/subscribe** ในตัวของ PostgreSQL หนึ่ง session สามารถส่ง notification บน channel หนึ่ง และ session อื่น ๆ ที่ listen อยู่บน channel นั้นจะได้รับมันทันที เป็นวิธีที่เบาในการ push event แบบ real-time จากฐานข้อมูลโดยไม่ต้อง polling

## กลไกพื้นฐาน

```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 subscribe ไปยัง channel; NOTIFY publish ไปยังมัน (พร้อม text payload ที่ใส่หรือไม่ก็ได้) ผู้ listen จะได้รับการแจ้งเตือนแบบ asynchronous โดยไม่ต้อง polling

## การ trigger NOTIFY โดยอัตโนมัติ (รูปแบบที่พบบ่อย)

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

การรวม NOTIFY กับ **trigger** ช่วยให้ฐานข้อมูล push event โดยอัตโนมัติเมื่อข้อมูลเปลี่ยนแปลง (มี order ใหม่, อัปเดตสถานะ) แอปพลิเคชันเซิร์ฟเวอร์ที่ listen อยู่บน channel จะตอบสนองแบบ real-time

## แอปพลิเคชันใช้มันอย่างไร

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

## ข้อจำกัดที่ควรรู้

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

## ทำไมจึงสำคัญ

`LISTEN`/`NOTIFY` เป็นฟีเจอร์ของ PostgreSQL ที่มีประโยชน์และค่อนข้างไม่เป็นที่รู้จักมากนัก ซึ่งให้ **pub/sub messaging ในตัว** มีคุณค่าต่อการเพิ่ม **การตอบสนองแบบ real-time** ให้กับแอปพลิเคชันโดยไม่ต้อง polling

คุณค่าหลักคือการช่วยให้ฐานข้อมูล **push event** ไปยัง session ของแอปพลิเคชันที่ listen อยู่ได้ทันทีเมื่อมีบางอย่างเกิดขึ้น (order ใหม่, การเปลี่ยนสถานะ) โดยทั่วไปจะรวมกับ **trigger** เพื่อให้ข้อมูลที่เปลี่ยนแปลงแจ้งเตือนผู้ listen โดยอัตโนมัติ ซึ่งแอปพลิเคชันเซิร์ฟเวอร์จะตอบสนอง (push ไปยัง websocket, invalidate แคช, trigger งานเบื้องหลัง)

สิ่งนี้มีคุณค่าเพราะให้พฤติกรรมแบบ event-driven และ real-time โดยไม่มีความสิ้นเปลืองจากการ **polling** ฐานข้อมูลซ้ำ ๆ เพื่อตรวจหาการเปลี่ยนแปลง (รูปแบบที่พบบ่อยและสิ้นเปลือง ที่ LISTEN/NOTIFY แทนที่ได้อย่างหมดจด)

การเข้าใจกลไก (LISTEN เพื่อ subscribe, NOTIFY เพื่อ publish พร้อม trigger สำหรับการแจ้งเตือนอัตโนมัติเมื่อข้อมูลเปลี่ยน) และวิธีที่แอปพลิเคชันใช้มัน (listen หา event เพื่อขับเคลื่อนการตอบสนองแบบ real-time) มีประโยชน์ต่อการสร้างแอปพลิเคชันที่ตอบสนองได้และเป็น event-driven โดยใช้แค่ PostgreSQL

ที่สำคัญไม่แพ้กันคือการรู้ **ข้อจำกัด**: notification **ไม่ถูก persist** (จะหายไปหากไม่มีใคร listen ไม่มีการรับประกัน durability) มี payload ขนาดเล็ก และยิงเฉพาะหลัง commit เท่านั้น ดังนั้นมันเหมาะกับการส่งสัญญาณ real-time แบบเบา *ไม่ใช่* สิ่งทดแทน message broker ที่มี durability (RabbitMQ, Kafka) เมื่อความน่าเชื่อถือและความคงทนของข้อมูลมีความสำคัญ

เนื่องจากการตอบสนองแบบ real-time เป็นความต้องการที่พบบ่อย และ LISTEN/NOTIFY มอบวิธีในตัวที่ไม่ต้อง polling เพื่อให้บรรลุสิ่งนี้ในกรณีที่เบา การเข้าใจมัน ทั้งกลไก pub/sub รูปแบบ trigger และที่สำคัญคือข้อจำกัด (เมื่อใดที่เพียงพอ เทียบกับเมื่อใดที่ต้องการ broker จริง) จึงเป็นความรู้ PostgreSQL ที่มีคุณค่าและเกี่ยวข้องเชิงปฏิบัติสำหรับการสร้างแอปพลิเคชันแบบ event-driven เป็นฟีเจอร์ในตัวที่มีประโยชน์ซึ่งมักถูกมองข้าม