PostgreSQL LISTEN/NOTIFY: เมื่อมันเพียงพอสำหรับการอัปเดตแบบเรียลไทม์

ปัญหาที่ LISTEN/NOTIFY พยายามแก้\n\n"การอัปเดตแบบสด" ใน UI ของผลิตภัณฑ์โดยปกติหมายถึงหน้าจอเปลี่ยนเร็วหลังจากมีบางอย่างเกิดขึ้น โดยไม่ต้องให้ผู้ใช้รีเฟรช เลขบนแดชบอร์ดเพิ่มขึ้น แบนด์จ์สีแดงปรากฏในกล่องขาเข้า ผู้ดูแลเห็นคำสั่งซื้อใหม่ หรือมีทอสต์เด้งขึ้นว่า “Build finished” หรือ “Payment failed” จุดสำคัญคือความรู้สึกทันที แม้มันอาจใช้เวลาหนึ่งหรือสองวินาทีจริงๆ\n\nทีมหลายทีมเริ่มด้วยการ polling: เบราว์เซอร์ถามเซิร์ฟเวอร์ว่า "มีอะไรใหม่ไหม" ทุกไม่กี่วินาที การ polling ใช้งานได้ แต่มีข้อเสียสองอย่างที่พบบ่อย\n\nอันดับแรก มันรู้สึกหน่วงเพราะผู้ใช้จะเห็นการเปลี่ยนแปลงก็ต่อเมื่อการ poll ครั้งถัดไปเกิดขึ้น\n\nอันดับที่สอง มันอาจแพงเพราะคุณตรวจสอบซ้ำ ๆ ถึงแม้จะไม่มีอะไรเปลี่ยน แค่คูณด้วยผู้ใช้เป็นพัน ๆ ก็กลายเป็นเสียงรบกวน\n\nPostgreSQL LISTEN/NOTIFY มีไว้สำหรับกรณีที่ง่ายกว่า: "บอกฉันเมื่อมีอะไรเปลี่ยน" แทนที่จะถามซ้ำ ๆ แอปของคุณสามารถรอและตอบสนองเมื่อฐานข้อมูลส่งสัญญาณเล็ก ๆ\n\nมันเหมาะกับ UI ที่แค่ต้องการการกระตุ้นเล็ก ๆ ตัวอย่างเช่น:\n\n- ไทล์แดชบอร์ดควรรีเฟรชเพราะยอดรวมเปลี่ยน\n- ตัวนับแบดจ์ควรอัปเดตเพราะมีรายการใหม่\n- การแจ้งเตือนภายในควรปรากฏเพราะสถานะงานเปลี่ยน\n\nการแลกเปลี่ยนคือความเรียบง่ายเทียบกับการรับประกัน LISTEN/NOTIFY เพิ่มง่ายเพราะมีมาแล้วใน Postgres แต่มันไม่ใช่ระบบส่งข้อความเต็มรูปแบบ การแจ้งเตือนเป็นแค่เบาะแส ไม่ใช่บันทึกที่ทนทาน หาก listener ตัดการเชื่อมต่อ มันอาจพลาดสัญญาณ\n\nวิธีใช้เชิงปฏิบัติ: ให้ NOTIFY ปลุกแอปของคุณ จากนั้นให้แอปอ่านข้อมูลจริงจากตาราง\n\n## วิธีการทำงานของ PostgreSQL LISTEN/NOTIFY แบบเข้าใจง่าย\n\nคิดว่า PostgreSQL LISTEN/NOTIFY เป็นกริ่งประตูเล็ก ๆ ในฐานข้อมูลของคุณ แอปของคุณสามารถรอให้กริ่งดัง และอีกส่วนของระบบสามารถกดกริ่งเมื่อมีการเปลี่ยนแปลง\n\nการแจ้งเตือนมีสองส่วน: ชื่อช่อง (channel) และ payload แบบทางเลือก ช่องเหมือนป้ายหัวข้อ (เช่น orders_changed) ส่วน payload เป็นข้อความสั้น ๆ ที่แนบมา (เช่น id ของคำสั่งซื้อ) PostgreSQL ไม่บังคับโครงสร้าง ดังนั้นทีมมักส่งสตริง JSON ขนาดเล็ก\n\n### ใครกดกริ่ง?\n\nการแจ้งเตือนสามารถถูกกระตุ้นจากโค้ดแอป (API server ของคุณรัน NOTIFY) หรือจากฐานข้อมูลเองผ่าน trigger (trigger รัน NOTIFY หลังการ INSERT/UPDATE/DELETE)\n\n- โค้ดแอปตามปกติอ่านเข้าใจและทดสอบง่ายกว่า\n- trigger มีประโยชน์เมื่อผู้เขียนหลายคนแก้ไขตารางเดียวกันและคุณต้องการพฤติกรรมสอดคล้องกัน\n\nฝั่งรับ แอปเซิร์ฟเวอร์ของคุณเปิดการเชื่อมต่อฐานข้อมูลและรัน LISTEN channel_name การเชื่อมต่อนั้นจะเปิดค้างไว้ เมื่อมี NOTIFY channel_name, 'payload' เกิดขึ้น PostgreSQL จะส่งข้อความไปยังการเชื่อมต่อทั้งหมดที่ฟังช่องนั้น แล้วแอปของคุณก็ตอบสนอง (รีเฟรชแคช ดึงแถวที่เปลี่ยน ส่งเหตุการณ์ WebSocket ไปยังเบราว์เซอร์ ฯลฯ)\n\n### NOTIFY ทำอะไร (และไม่ทำ)\n\nNOTIFY ควรถูกเข้าใจว่าเป็นสัญญาณ ไม่ใช่บริการจัดส่ง:\n\n- มันบอกผู้ฟังว่า "มีบางอย่างเกิดขึ้น" ตอนนี้เลย\n- มันไม่รับประกันว่าข้อความทุกอันจะถูกรับ (listener ที่ตัดการเชื่อมต่อจะพลาด)\n- มันไม่ใช่คิว (ข้อความไม่ได้ถูกเก็บไว้เพื่อใช้ทีหลัง)\n- ขนาด payload ถูกจำกัดและควรเล็ก\n- มันควรชี้ไปที่ข้อมูล ไม่ใช่ทดแทนข้อมูล (ส่ง id แล้วค่อย query รายละเอียด)\n\nถ้าใช้แบบนี้ PostgreSQL LISTEN/NOTIFY สามารถขับเคลื่อนการอัปเดต UI แบบสดได้โดยไม่ต้องเพิ่มโครงสร้างพื้นฐานเพิ่มเติม\n\n## เมื่อ LISTEN/NOTIFY เพียงพอสำหรับการอัปเดต UI แบบสด\n\nLISTEN/NOTIFY เหมาะเมื่อ UI ของคุณต้องการแค่การกระตุ้นว่ามีการเปลี่ยนแปลง ไม่ใช่สตรีมเหตุการณ์เต็มรูปแบบ คิดว่าเป็น "รีเฟรชวิดเจ็ตนี้" หรือ "มีรายการใหม่" แทนที่จะเป็น "ประมวลผลการคลิกทุกครั้งตามลำดับ"\n\nมันทำงานได้ดีเมื่อฐานข้อมูลเป็นแหล่งความจริงของคุณอยู่แล้วและคุณอยากให้ UI อยู่ในสถานะสอดคล้องกัน รูปแบบทั่วไปคือ: เขียนแถว ส่งการแจ้งเตือนเล็ก ๆ ที่มี ID แล้วให้ UI (หรือ API) ดึงสถานะล่าสุด\n\nLISTEN/NOTIFY มักเพียงพอเมื่อเงื่อนไขเหล่านี้เป็นจริงส่วนใหญ่:\n\n- ข้อความเป็นสัญญาณเล็ก ๆ ว่า "มีอะไรเปลี่ยน" ไม่ใช่ payload เต็ม\n- ปริมาณเหตุการณ์ต่ำถึงปานกลาง (การระเบิดเป็นช่วง ๆ รับได้ แต่การไหลสูงต่อเนื่องไม่ใช่)\n- ถ้าผู้ใช้พลาดการแจ้งเตือน UI สามารถกู้คืนได้ด้วยการโหลดใหม่หรือ polling สั้น ๆ\n- คุณให้ความสำคัญกับความเรียบง่ายมากกว่าการรับประกันการส่งที่สมบูรณ์แบบ (บ่อยสำหรับผลิตภัณฑ์ช่วงแรกและเครื่องมือภายใน)\n- คุณมีฐานข้อมูลหลักเพียงชุดเดียวและต้องการลดความซับซ้อนของระบบ\n\nตัวอย่างที่จับต้องได้: แดชบอร์ดฝ่ายสนับสนุนภายในแสดง "ตั๋วที่เปิด" และแบดจ์สำหรับ "โน้ตใหม่" เมื่อตัวแทนเพิ่มโน้ต backend ของคุณเขียนมันลงใน Postgres และ NOTIFY ticket_changed พร้อม ID ของตั๋ว เบราว์เซอร์ได้รับมันผ่าน WebSocket และดึงเฉพาะการ์ดตั๋วนั้นขึ้นมาใหม่ ไม่มีโครงสร้างพื้นฐานเพิ่มเติม และ UI ยังคงรู้สึกสด\n\n## จุดที่ LISTEN/NOTIFY เริ่มมีปัญหา\n\nLISTEN/NOTIFY อาจให้ความรู้สึกดีในตอนแรก แต่มีข้อจำกัดชัดเจน ข้อจำกัดเหล่านี้ปรากฏเมื่อคุณใช้การแจ้งเตือนเหมือนระบบข้อความแทนที่จะเป็นการแตะเบา ๆ ที่ไหล่\n\nช่องว่างที่ใหญ่สุดคือความทนทาน (durability) NOTIFY ไม่ใช่งานคิว หากไม่มีคนฟังในขณะนั้น ข้อความจะหายไป แม้เมื่อมี listener เชื่อมต่อ การล้มเหลว การปรับใช้ การสะดุดของเครือข่าย หรือการรีสตาร์ทฐานข้อมูลก็อาจทำให้การเชื่อมต่อหลุด คุณจะไม่ได้รับการแจ้งเตือนที่พลาดเหล่านั้นคืนโดยอัตโนมัติ\n\nการตัดการเชื่อมต่อเป็นปัญหาโดยเฉพาะสำหรับฟีเจอร์ที่แสดงต่อผู้ใช้ ลองจินตนาการแดชบอร์ดที่แสดงคำสั่งซื้อใหม่ แท็บเบราว์เซอร์หลับ WebSocket รีคอนเน็กต์ และ UI ดู "ค้าง" เพราะพลาดเหตุการณ์บางส่วน คุณสามารถแก้ทางนี้ได้ แต่วิธีแก้ไม่ใช่แค่ "LISTEN/NOTIFY" อีกต่อไป: คุณต้องสร้างสถานะอีกครั้งโดยการ query ฐานข้อมูลและใช้ NOTIFY เป็นแค่เบาะแสให้รีเฟรช\n\nการกระจาย (fan-out) เป็นปัญหาทั่วไปอีกอย่าง เหตุการณ์หนึ่งอาจปลุก listener หลายร้อยหรือหลายพันคน (หลายแอปเซิร์ฟเวอร์ หลายผู้ใช้) ถ้าคุณใช้ช่องเดียวน่ารำคาญอย่าง orders ทุก listener จะตื่นขึ้นแม้มีผู้ใช้คนเดียวที่สนใจ นั่นอาจสร้างการระเบิดของ CPU และแรงกดดันการเชื่อมต่อในเวลาที่ไม่เหมาะสม\n\nขนาด payload และความถี่เป็นกับดักสุดท้าย payload ของ NOTIFY เล็ก และเหตุการณ์ความถี่สูงอาจสะสมเร็วกว่าที่ไคลเอนต์จะจัดการได้\n\nสังเกตสัญญาณเหล่านี้:\n\n- คุณต้องการการส่งที่รับประกัน การลองซ้ำ หรือการเรียงลำดับ\n- ไคลเอนต์รีคอนเน็กต์บ่อยและต้องไม่พลาดการอัปเดต\n- ช่องเดียวปลุก listener จำนวนมากที่ส่วนใหญ่ไม่สนใจเหตุการณ์\n- คุณส่ง payload ขนาดใหญ่หรือยิงเหตุการณ์หลายครั้งต่อวินาที\n\nเมื่อนั้น ให้เก็บ NOTIFY เป็นเพียง "การกระตุ้น" แล้วย้ายความน่าเชื่อถือไปไว้ที่ตารางหรือ message broker ที่เหมาะสม\n\n## ขั้นตอนทีละขั้น: รูปแบบง่าย ๆ ที่ใช้ได้จริง\n\nรูปแบบที่เชื่อถือได้กับ LISTEN/NOTIFY คือถือ NOTIFY เป็นการกระตุ้น ไม่ใช่แหล่งความจริง แถวในฐานข้อมูลคือความจริง การแจ้งเตือนบอกแอปว่าเมื่อใดควรมอง\n\n### 1) เขียน commit แล้วค่อย notify\n\nทำการเขียนภายในธุรกรรม และส่งการแจ้งเตือนเฉพาะหลังจากการเปลี่ยนแปลงข้อมูลถูก commit ถ้าคุณ notify เร็วเกินไป ไคลเอนต์อาจตื่นขึ้นมาแล้วหา data ไม่เจอ\n\nการตั้งค่าทั่วไปคือ trigger ที่ยิงเมื่อ INSERT/UPDATE แล้วส่งข้อความเล็ก ๆ\n\nsql\nNOTIFY dashboard_updates, '{\\\"type\\\":\\\"order_changed\\\",\\\"order_id\\\":123}'::text;\n\n\n### 2) เลือกชื่อช่องง่าย ๆ และ payload ขนาดเล็ก\n\nการตั้งชื่อช่องทำงานได้ดีเมื่อมันตรงกับวิธีที่คนคิดเกี่ยวกับระบบ ตัวอย่าง: dashboard_updates, user_notifications, หรือ per-tenant เช่น tenant_42_updates\n\nเก็บ payload ให้เล็ก ใส่เฉพาะตัวระบุและ type ไม่ใช่เรคคอร์ดเต็ม รูปแบบดีฟอลต์ที่ใช้ได้คือ:\n\n- type (เกิดอะไรขึ้น)\n- id (อะไรเปลี่ยน)\n- tenant_id หรือ user_id แบบเลือกใส่\n\nวิธีนี้ช่วยลดแบนด์วิดท์และหลีกเลี่ยงการรั่วไหลของข้อมูลที่ละเอียดอ่อนในบันทึกการแจ้งเตือน\n\n### 3) จัดการการเชื่อมต่อใหม่และสมัครใหม่ทุกครั้งที่เชื่อม\n\nการเชื่อมต่อจะหลุด วางแผนรับมันไว้\n\nเมื่อเชื่อม ให้รัน LISTEN สำหรับทุกช่องที่ต้องการ เมื่อหลุดให้ reconnect ด้วย backoff สั้น ๆ เมื่อต่อใหม่แล้วให้รัน LISTEN อีกครั้ง (การสมัครจะไม่คงอยู่) หลัง reconnect ให้ทำการ refetch การเปลี่ยนแปลงล่าสุดอย่างรวดเร็วเพื่อคลุมเหตุการณ์ที่พลาดไป\n\n### 4) อัปเดต UI: ดึงข้อมูลก่อน แล้วค่อยแพตช์\n\nสำหรับการอัปเดต UI แบบสดส่วนใหญ่ การ refetch เป็นวิธีที่ปลอดภัยที่สุด: ไคลเอนต์ได้รับ {type, id} แล้วถามเซิร์ฟเวอร์เพื่อสถานะล่าสุด\n\nการแพตช์แบบเพิ่มทีละน้อยอาจเร็วกว่า แต่ก็ผิดพลาดได้ง่าย (เหตุการณ์เรียงลำดับผิด ล้มเหลวบางส่วน) ทางสายกลางที่ดีคือ: refetch ชิ้นเล็ก ๆ (แถวคำสั่งซื้อหนึ่งแถว การ์ดตั๋วหนึ่งใบ จำนวนบนแบดจ์หนึ่งค่า) และให้การคำนวณรวมขนาดใหญ่อยู่บนตัวจับเวลาแบบสั้น\n\n## รูปแบบการสเกลสำหรับแดชบอร์ดและการแจ้งเตือน\n\nเมื่อคุณขยายจากแดชบอร์ดผู้ดูแลเดี่ยวเป็นผู้ใช้หลายคนดูตัวเลขเดียวกัน นิยมปฏิบัติที่ดีมีความสำคัญกว่าการเขียน SQL ฉลาด ๆ LISTEN/NOTIFY ยังใช้งานได้ดี แต่คุณต้องกำหนดวิธีไหลของเหตุการณ์จากฐานข้อมูลไปยังเบราว์เซอร์\n\nรูปแบบพื้นฐานทั่วไปคือ: แต่ละอินสแตนซ์แอปเปิดการเชื่อมต่อยาว ๆ หนึ่งการเชื่อมต่อที่ LISTEN แล้วส่งอัปเดตไปยังไคลเอนต์ที่เชื่อม การตั้งค่า "หนึ่ง listener ต่ออินสแตนซ์" นี้เรียบง่ายและมักพอใช้ถ้าคุณมีเซิร์ฟเวอร์ไม่กี่เครื่องและยอมรับการ reconnect เป็นบางครั้งได้\n\nถ้าคุณมีอินสแตนซ์แอปจำนวนมาก (หรือ worker แบบ serverless) บริการ listener ร่วมอาจง่ายกว่า กระบวนการเล็ก ๆ หนึ่งตัวฟังข้อมูลแล้วส่งต่ออัปเดตให้สแต็กที่เหลือ ซึ่งยังเป็นจุดเดียวในการเพิ่มการ batch, metrics, และ backpressure\n\nสำหรับเบราว์เซอร์ คุณมักส่งผ่าน WebSockets (สองทาง เหมาะกับ UI โต้ตอบ) หรือ Server-Sent Events (SSE) (ทางเดียว ง่ายกว่าเพื่อแดชบอร์ด) อย่างไรก็ตาม หลีกเลี่ยงการส่ง "รีเฟรชทุกอย่าง" ส่งสัญญาณกะทัดรัดอย่าง "order 123 changed" เพื่อให้ UI ดึงเฉพาะที่ต้องการ\n\nเพื่อป้องกัน UI กระพือ ให้เพิ่มการป้องกันเล็กน้อย:\n\n- ดีบาวน์การระเบิด (เช่น 100 ถึง 500 ms) ก่อนส่งไปยังไคลเอนต์\n- รวมซ้ำ (บันทึกเดียวเปลี่ยน 10 ครั้ง ส่ง 1 อัปเดต)\n- ใช้ "dirty flags" ต่อวิดเจ็ตแทนการรีเฟรชทั้งหน้า\n\nการออกแบบช่องก็สำคัญ แทนที่จะใช้ช่องแบบ global เดียว ให้แยกตาม tenant ทีม หรือฟีเจอร์ เพื่อให้ไคลเอนต์ได้รับเหตุการณ์ที่เกี่ยวข้องเท่านั้น เช่น: notify:tenant_42:billing และ notify:tenant_42:ops\n\n## ข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง\n\nLISTEN/NOTIFY รู้สึกเรียบง่าย นั่นคือเหตุผลที่ทีมมักปล่อยใช้งานเร็วแล้วเซอร์ไพรส์ตอนขึ้นโปรดักชัน ปัญหาส่วนใหญ่เกิดจากการปฏิบัติต่อมันเหมือนคิวข้อความที่รับประกันได้\n\n### 1) การปฏิบัติต่อการแจ้งเตือนเป็นข้อความทนทาน\n\nถ้าแอปของคุณรีคอนเน็กต์ (deploy, network blip, DB failover) any NOTIFY ที่ส่งในช่วงที่คุณออฟไลน์จะหาย วิธีแก้คือทำให้การแจ้งเตือนเป็นสัญญาณ แล้วตรวจสอบฐานข้อมูลอีกครั้ง\n\nรูปแบบปฏิบัติได้: เก็บเหตุการณ์จริงในตาราง (มี id และ created_at) แล้วเมื่อรีคอนเน็กต์ให้ดึงข้อมูลที่ใหม่กว่าค่า id ล่าสุดที่เห็น\n\n### 2) การใส่ payload หนักเกินไป\n\npayload ของ LISTEN/NOTIFY ไม่ได้ออกแบบมาสำหรับ JSON ก้อนใหญ่ ขนาดใหญ่เพิ่มงาน parsing และโอกาสโดนขีดจำกัด\n\nใช้ payload สำหรับฮินต์เล็ก ๆ เช่น "order:123" แล้วแอปค่อยอ่านสถานะล่าสุดจากฐานข้อมูล\n\n### 3) ผสมระหว่าง “สัญญาณ” และ “การดึงข้อมูล”\n\nข้อผิดพลาดทั่วไปคือออกแบบ UI ให้พึ่ง payload ราวกับมันเป็นแหล่งความจริง นั่นทำให้การเปลี่ยนแปลงสกีมาและเวอร์ชันไคลเอนต์กลายเป็นปัญหา\n\nแยกความรับผิดชอบให้ชัด: แจ้งว่าอะไรเปลี่ยน แล้วดึงข้อมูลปัจจุบันด้วย query ปกติ\n\n### 4) Trigger ที่ยิงบ่อยเกินไป\n\nTrigger ที่ NOTIFY ในทุกการเปลี่ยนแปลงแถวอาจทำให้ระบบล้น โดยเฉพาะกับตารางที่มีความหนาแน่นสูง\n\nNotify เฉพาะเมื่อมีการเปลี่ยนแปลงที่มีความหมาย (เช่น การเปลี่ยนสถานะ) ถ้าอัปเดตที่มีเสียงดังมาก ให้รวมเป็นกลุ่ม (หนึ่ง notify ต่อธุรกรรมหรือหน้าต่างเวลา) หรือลดการอัปเดตที่อยู่ใน path ของการแจ้งเตือน\n\n### 5) มองข้าม backpressure ใน UI\n\nแม้ฐานข้อมูลจะส่งการแจ้งเตือนได้ ไคลเอนต์ของคุณก็ยังอาจอัดไม่ไหว แดชบอร์ดที่ re-render ทุกเหตุการณ์อาจค้าง\n\nดีบาวน์อัปเดตบนไคลเอนต์ รวบรวมการระเบิดเป็นรีเฟรชเดียว และเลือกใช้ "invalidate and refetch" มากกว่า "apply every delta" ตัวอย่าง: แบนเนอร์แจ้งเตือนอาจอัปเดตทันที แต่รายการใน dropdown ควรรีเฟรชไม่เกินทุกไม่กี่วินาที\n\n## เช็คลิสต์ด่วน: ตัดสินใจว่า LISTEN/NOTIFY เหมาะหรือไม่\n\nLISTEN/NOTIFY ดีเมื่อคุณต้องการสัญญาณสั้น ๆ ว่า "มีอะไรเปลี่ยน" เพื่อให้แอปดึงข้อมูลใหม่ มันไม่ใช่ระบบส่งข้อความเต็มรูปแบบ\n\nก่อนสร้าง UI รอบมัน ให้ตอบคำถามเหล่านี้:\n\n- ถ้า listener ออฟไลน์หนึ่งนาที จะพลาดเหตุการณ์แล้วเกิดปัญหาหรือไม่? ถ้าพลาดไม่ได้ ให้หาการส่งที่ทนทานและเล่นซ้ำได้\n- "ใกล้เคียงเรียลไทม์" เพียงพอไหม? ถ้าผู้ใช้ยอมรับความหน่วงสั้น ๆ ระหว่าง deploys หรือปัญหาเครือข่าย LISTEN/NOTIFY มักพอใช้\n- อัตราระเบิดสูงสุดของคุณเป็นเท่าไร? ไม่กี่เหตุการณ์ต่อวินาทีหรือมีการสแปลชเป็นระยะ ๆ เป็นจุดที่เหมาะ Sustained high volume จะทำให้ช่องเสียงดังและจัดการยาก\n- มีผู้ฟังพร้อมกันกี่คน? หนึ่งหรือไม่กี่ worker ง่าย แต่ร้อยหรือพันคนมักต้องการชั้น fan-out (เซิร์ฟเวอร์ของคุณ) แทนให้ทุกคนเชื่อมต่อโดยตรง\n- คุณต้องการการเรียงลำดับเข้มงวดข้ามหลายประเภทเหตุการณ์หรือไม่? ถ้าแดชบอร์ดต้องการว่า "A ต้องถูกประมวลผลก่อน B" ข้ามหลายสตรีม จะซับซ้อนเร็วมาก\n\nกฎปฏิบัติ: ถ้าคุณสามารถถือ NOTIFY เป็นการกระตุ้น ("ไปอ่านแถวใหม่") มากกว่าจะเป็น payload เอง คุณอยู่ในโซนปลอดภัย\n\nตัวอย่าง: แดชบอร์ดผู้ดูแลแสดงคำสั่งซื้อใหม่ ถ้า notification หายไป การ polling ครั้งถัดไปหรือการรีเฟรชหน้าจอก็ยังแสดงจำนวนที่ถูกต้อง นั่นคือการใช้งานที่ดี แต่ถ้าคุณส่ง "charge this card" หรือ "ship this package" การพลาดเหตุการณ์หนึ่งครั้งอาจเป็นเหตุการณ์ร้ายแรง\n\n## ตัวอย่าง: แดชบอร์ดสดและการแจ้งเตือนผู้ใช้\n\nสมมติแอปขายของขนาดเล็ก: แดชบอร์ดแสดงรายได้วันนี้ ยอดคำสั่งซื้อรวม และรายการ "คำสั่งซื้อล่าสุด" ในขณะเดียวกัน พนักงานขายแต่ละคนควรได้การแจ้งเตือนเมื่อคำสั่งซื้อที่เขาดูแลถูกชำระหรือจัดส่ง\n\nแนวทางง่าย ๆ คือถือ PostgreSQL เป็นแหล่งความจริง และใช้ LISTEN/NOTIFY เป็นการเคาะบ่าเมื่อมีการเปลี่ยนแปลง\n\nเมื่อสร้างคำสั่งซื้อหรือสถานะเปลี่ยน backend ของคุณทำสองอย่างในคำขอเดียว: เขียนแถวแล้วส่ง NOTIFY พร้อม payload เล็ก ๆ (มักเป็น id และประเภทเหตุการณ์) UI จะไม่พึ่ง payload ของ NOTIFY เป็นข้อมูลเต็ม\n\nลำดับปฏิบัติการที่เป็นไปได้:\n\n- เขียนการเปลี่ยนแปลงคำสั่งซื้อในธุรกรรม\n- หลัง commit, NOTIFY orders_events ด้วย {\\\"type\\\":\\\"status_changed\\\",\\\"order_id\\\":123}\n- listener ฝั่ง backend รับเหตุการณ์และส่งต่อไปยังเบราว์เซอร์ที่เชื่อม (WebSocket หรือ SSE)\n- แดชบอร์ดดึงเฉพาะที่ต้องการ: แถวคำสั่งล่าสุดตาม ID และยอดรวมบนตัวจับเวลาแบบสั้น (เช่น ทุก 2–5 วินาที) แทนการคำนวณใหม่บนทุกเหตุการณ์\n- การแจ้งเตือนผู้ใช้เป็นการส่งแบบกำหนดเป้าหมาย: เฉพาะพนักงานขายที่ติดตามคำสั่งซื้อนั้นจะได้ทอสต์ "paid" หรือ "shipped"\n\nวิธีนี้ทำให้ NOTIFY น้ำหนักเบาและจำกัดการ query ที่แพง\n\nเมื่อทราฟฟิกเติบโต ข้อจำกัดจะเริ่มปรากฏ: การระเบิดของเหตุการณ์อาจครอบงำ listener เดียว การแจ้งเตือนอาจหายเมื่อรีคอนเน็กต์ และคุณจะเริ่มต้องการการส่งที่ทนทานและการเล่นซ้ำ นั่นมักเป็นเวลาที่คุณเพิ่มชั้นที่เชื่อถือได้มากขึ้น (ตาราง outbox + worker แล้วค่อยใช้ broker ถ้าจำเป็น) ในขณะที่ยังคงให้ Postgres เป็นแหล่งความจริง\n\n## เมื่อควรยกระดับไปยัง broker เฉพาะทาง\n\nLISTEN/NOTIFY ดีเมื่อคุณต้องการสัญญาณ "มีอะไรเปลี่ยน" แบบเร็ว แต่มันไม่ได้ถูกออกแบบเป็นระบบข้อความเต็มรูปแบบ เมื่อคุณเริ่มพึ่งเหตุการณ์เป็นแหล่งความจริง ก็ควรเพิ่ม broker\n\n### สัญญาณชัดว่าคุณโตเกิน LISTEN/NOTIFY แล้ว\n\nถ้ามีข้อเหล่านี้ เก้าอี้ broker จะช่วยได้:\n\n- คุณต้องการ durability: เหตุการณ์ต้องไม่สูญหายถ้าแอปรีสตาร์ทหรือ DB failover\n- คุณต้องการการลองซ้ำและการจัดการ dead-letter: ถ้าคอนซูเมอร์ล้มเหลว ข้อความต้องถูกลองใหม่และติดตามได้\n- คุณต้องการ consumer groups: worker หลายตัวแบ่งโหลดโดยไม่ประมวลผลซ้ำ\n- คุณต้องการ auditing และ replay: "แสดงทุกอย่างที่เกิดขึ้นชั่วโมงที่ผ่านมา" หรือ "สร้างมุมมองนี้ใหม่จากเหตุการณ์"\n- คุณต้องการ backpressure ที่ควบคุมได้: ผู้ผลิตไม่ควรทำให้คอนซูเมอร์ช้าจนถูกล้น\n\nLISTEN/NOTIFY ไม่เก็บข้อความไว้เพื่อใช้ทีหลัง มันเป็นสัญญาณแบบ push ไม่ใช่ log ที่เก็บถาวร นั่นเหมาะกับ "รีเฟรชวิดเจ็ตแดชบอร์ด" แต่เสี่ยงกับงานอย่าง "เรียกเก็บบัตร" หรือ "จัดส่งพัสดุ"\n\n### broker เพิ่มอะไรให้ (อธิบายแบบง่าย)\n\nbroker ให้โมเดลการไหลของข้อความจริง: คิว (งานที่ต้องทำ), ท็อปปิก (กระจายไปหลายคน), การเก็บรักษา (เก็บข้อความเป็นนาทีถึงวัน), และการรับรอง (consumer ยืนยันการประมวลผล) สิ่งนี้ทำให้คุณแยก "ฐานข้อมูลเปลี่ยน" ออกจาก "สิ่งที่ควรเกิดขึ้นเพราะมันเปลี่ยน"\n\nคุณไม่จำเป็นต้องเลือกเครื่องมือซับซ้อนสุด ตัวเลือกทั่วไปที่คนพิจารณาคือ Redis (pub/sub หรือ streams), NATS, RabbitMQ และ Kafka ทางเลือกขึ้นกับว่าคุณต้องการคิวงานเรียบง่าย การกระจายไปหลายบริการ หรือต้องการเล่นซ้ำประวัติหรือไม่\n\n### แผนการย้ายแบบค่อยเป็นค่อยไป\n\nคุณสามารถย้ายได้โดยไม่ต้องเขียนใหม่ทั้งหมด รูปแบบปฏิบัติคือเก็บ NOTIFY เป็นสัญญาณปลุกในขณะที่ broker กลายเป็นแหล่งการส่ง

\nเริ่มจากเขียน "event row" ลงในตารางภายในธุรกรรมเดียวกับการเปลี่ยนแปลงธุรกิจ แล้วให้ worker เผยแพร่อีเวนต์นั้นไปยัง broker ในช่วงการเปลี่ยนผ่าน NOTIFY ยังบอกเลเยอร์ UI ว่า "เช็คเหตุการณ์ใหม่" ขณะที่ worker พื้นหลังดึงจาก broker พร้อมการลองซ้ำและการตรวจสอบ \nด้วยวิธีนี้ แดชบอร์ดยังคงตอบสนอง และเวิร์กโฟลว์ที่สำคัญหยุดพึ่งพาการแจ้งเตือนที่พยายามเท่านั้น \n## ขั้นตอนต่อไป: ปล่อยเวอร์ชันเล็ก ๆ แล้วปรับปรุงอย่างปลอดภัย\n\nเลือกหน้าจอหนึ่งหน้า (ไทล์แดชบอร์ด, จำนวนแบดจ์, หรือทอสต์ "การแจ้งเตือนใหม่") แล้วเชื่อมต่อแบบ end-to-end ด้วย LISTEN/NOTIFY คุณจะได้ผลลัพธ์ที่มีประโยชน์เร็ว ตราบใดที่ขอบเขตแคบและวัดผลเมื่อใช้งานจริง\n\nเริ่มด้วยรูปแบบที่เชื่อถือได้ที่สุดเท่าที่ทำได้: เขียนแถว commit แล้วส่งสัญญาณเล็ก ๆ ว่าอะไรเปลี่ยน ใน UI ให้ตอบสนองต่อสัญญาณด้วยการดึงสถานะล่าสุด (หรือชิ้นที่ต้องการ) วิธีนี้ช่วยให้ payload เล็กและหลีกเลี่ยงบั๊กเมื่อนำเข้าลำดับเหตุการณ์ผิด\n\nเพิ่มการสังเกตการณ์พื้นฐานตั้งแต่ต้น คุณไม่จำเป็นต้องมีเครื่องมือหรูหรา แต่คุณต้องมีคำตอบเมื่อระบบเสียงดัง:\n\n- บันทึกการ reconnect และการเริ่มสมัคร (รวมเหตุผล)\n- ติดตามอัตราการ notify และการระเบิดสูงสุด\n- ติดตามอัตราการ fetch ที่ถูกทริกเกอร์โดยการแจ้งเตือน\n- มองหาลักษณะ "พลาดการอัปเดต" (ผู้ใช้ต้องรีเฟรช)\n\nเก็บสัญญา (contracts) ให้ตรงไปตรงมาและจดไว้ ตัดสินใจชื่อช่อง ชื่อเหตุการณ์ และรูปแบบ payload (แม้มันจะเป็นแค่ ID) แคตตาล็อกเหตุการณ์สั้น ๆ ใน repo ของคุณช่วยป้องกันการเบี้ยวของสัญญา\n\nถ้าคุณต้องการสร้างอย่างรวดเร็วและอยากคงสแต็กให้ง่าย แพลตฟอร์มอย่าง Koder.ai (koder.ai) สามารถช่วยคุณปล่อยเวอร์ชันแรกด้วย React UI, Go backend และ PostgreSQL แล้วค่อยปรับเมื่อความต้องการชัดขึ้น\n