Webhook vs Polling vs WebSocket ควรเลือกแบบไหนในระบบจริง

เวลาระบบหนึ่งต้อง “รู้ว่าอีกระบบหนึ่งเปลี่ยนสถานะแล้ว” หรือ “ส่งข้อมูลใหม่ให้ผู้ใช้อย่างเร็วที่สุด” คำถามที่ตามมามักจะไม่ใช่แค่เรื่อง API endpoint แต่เป็นเรื่องรูปแบบการสื่อสารทั้งก้อน

ควรให้ client คอยถามเองเป็นระยะ
ควรให้ server ส่ง callback กลับมาเมื่อมี event
หรือควรเปิด connection ค้างไว้แล้วคุยกันแบบ realtime ไปเลย

คำตอบสามแบบที่เจอบ่อยที่สุดคือ

polling
webhook
WebSocket

ทั้งสามแบบแก้ปัญหาเรื่อง “การรับรู้การเปลี่ยนแปลง” เหมือนกัน แต่ต้นทุน ความเสี่ยง และรูปแบบการดูแลใน production ต่างกันพอสมควร

บทความนี้อธิบายว่าแต่ละแบบคืออะไร เหมาะกับงานประเภทไหน และควรเลือกอย่างไรโดยไม่มองแค่เรื่องความเร็วหรือความทันสมัยเพียงอย่างเดียว

TL;DR

ถ้าจะสรุปแบบสั้นที่สุด

Polling เหมาะกับระบบที่เรียบง่าย ทน delay ได้ และอยากควบคุมฝั่ง client ให้ชัด
Webhook เหมาะกับ event-driven integration ระหว่างระบบ ที่อยากให้ต้นทางเป็นคนแจ้งเมื่อมีการเปลี่ยนแปลง
WebSocket เหมาะกับงาน interactive หรือ near-realtime ที่ client กับ server ต้องคุยต่อเนื่องกันจริง

ถ้ายังไม่แน่ใจ ให้ถามก่อนว่า

ใครเป็นคนเริ่มรู้ก่อนว่า state เปลี่ยน
ต้อง realtime แค่ไหน
ฝั่งไหนควบคุม infrastructure ได้มากกว่า
ถ้าส่งไม่สำเร็จ ต้อง retry และ dedup อย่างไร

ก่อนเลือก ต้องเข้าใจปัญหาที่กำลังแก้ก่อน

หลายทีมเริ่มจากเทคโนโลยีก่อน เช่น “ระบบนี้น่าจะใช้ WebSocket” หรือ “ของทันสมัยต้องเป็น webhook” แต่จริง ๆ คำถามแรกควรเป็น

ข้อมูลเปลี่ยนจากฝั่งไหน
อีกฝั่งต้องรู้เร็วแค่ไหน
การเปลี่ยนแปลงเกิดถี่หรือไม่
มี requirement เรื่อง offline/retry หรือไม่
ผู้ใช้ปลายทางรอได้กี่วินาที
ระบบภายนอกเชื่อถือได้แค่ไหน
เราควบคุม client กับ server ทั้งสองฝั่งหรือเปล่า

ถ้าตอบคำถามเหล่านี้ไม่ได้ชัด การเลือก pattern มักจะออกมาแบบตามกระแส มากกว่าตามธรรมชาติของงาน

Polling คืออะไร

Polling คือการที่ client เป็นฝ่ายคอยถาม server เป็นช่วง ๆ ว่ามีข้อมูลใหม่หรือสถานะเปลี่ยนหรือยัง

ตัวอย่างเช่น

หน้า order status เรียก GET /orders/{id} ทุก 5 วินาที
dashboard เรียก GET /metrics ทุก 30 วินาที
job monitor เรียก GET /jobs/{id} ทุก 3 วินาทีจนกว่างานจะเสร็จ

แนวคิดของมันตรงไปตรงมามาก

client ยังไม่รู้ว่ามีอะไรเปลี่ยน
จึงเลือกถามซ้ำเป็นรอบ

ข้อดีของ Polling

จุดแข็งของ polling คือความเรียบง่าย

มันไม่ต้องให้ server เปิด connection ค้าง
ไม่ต้องมี callback URL
ไม่ต้องคุยเรื่อง inbound access จากระบบภายนอก
ไม่ต้องแก้ network topology มาก

ถ้าระบบรับ delay ได้ระดับหนึ่ง เช่น 5 วินาที 10 วินาที หรือ 30 วินาที polling มักเป็นทางเลือกที่ implement ง่ายและดูแลง่ายกว่าที่หลายคนคิด

มันยังเหมาะในกรณีที่

client ควบคุมจังหวะเองได้
data เปลี่ยนไม่ถี่มาก
ไม่อยากแบก connection ระยะยาว
ระบบอยู่หลัง firewall หรือ callback เข้าไม่ได้ง่าย
อยากเริ่มแบบง่ายก่อนแล้วค่อย evolve ทีหลัง

ข้อเสียของ Polling

ข้อเสียคือมันเปลือง request เพราะต่อให้ไม่มีอะไรเปลี่ยน client ก็ยังถามอยู่ดี

ผลที่ตามมาคือ

มี traffic ที่ไม่ก่อ value จริงจำนวนมาก
response เดิมถูกส่งซ้ำเรื่อย ๆ
database หรือ cache ถูกอ่านถี่โดยไม่จำเป็น
latency ของการรับรู้การเปลี่ยนแปลงขึ้นกับ interval ที่ตั้งไว้

ถ้าตั้ง polling ถี่เกินไป ระบบจะหนัก
ถ้าตั้งห่างเกินไป ผู้ใช้จะเห็นข้อมูลช้า

ดังนั้น polling มักเป็นการแลกความเรียบง่ายกับประสิทธิภาพ

Webhook คืออะไร

Webhook คือการที่ระบบต้นทางเป็นฝ่ายเรียก HTTP callback มาหาอีกระบบเมื่อมี event เกิดขึ้น

แทนที่ฝั่งปลายทางจะต้องคอยถามว่า “มีอะไรเปลี่ยนหรือยัง” ฝั่งต้นทางจะพูดก่อนว่า “ตอนนี้มี event นี้เกิดขึ้นแล้ว”

ตัวอย่างเช่น

payment provider ส่ง payment.succeeded มาเมื่อจ่ายเงินสำเร็จ
GitHub ส่ง event มาที่ CI เมื่อมี push
Slack เรียก webhook เมื่อมี interaction หรือ event
ระบบภายในส่ง callback เมื่อ report generation เสร็จ

Webhook จึงเหมาะกับงานที่ต้นทางเป็นคนรู้ก่อนว่ามี event เกิดขึ้น และต้องการแจ้งปลายทางแบบ event-driven

ข้อดีของ Webhook

ข้อดีสำคัญคือมันลดการถามซ้ำแบบไม่จำเป็น

ถ้ายังไม่มี event ก็ไม่ต้องยิงอะไร
พอมี event ค่อยแจ้ง

ทำให้เหมาะกับงานพวกนี้มาก

payment status update
async job completion
workflow transitions
integration ระหว่างระบบ
notification จาก provider ภายนอก
approval หรือ bot actions บางประเภท

อีกข้อดีคือปลายทางไม่ต้องเดาช่วงเวลาเองว่าควรถามถี่แค่ไหน เพราะต้นทางเป็นคนส่งเมื่อมีการเปลี่ยนแปลงจริง

ข้อเสียของ Webhook

Webhook ไม่ได้ฟรีในเชิง operation

พอระบบหนึ่งเปิดให้รับ callback จากอีกระบบหนึ่ง ปัญหาที่ตามมาจะเยอะกว่าการมี endpoint ธรรมดา เช่น

จะยืนยันได้อย่างไรว่า request มาจากต้นทางจริง
ถ้ารับซ้ำต้อง dedup ยังไง
ถ้าปลายทางล่มแล้ว event หายไหม
ถ้าต้นทาง retry ต้องออกแบบ idempotency ยังไง
จะรับ event แบบ burst ยังไง
จะเก็บหลักฐานและ trace ยังไง

Webhook จึงมักดีมากในเชิง integration แต่ต้องมีวินัยด้าน verification, deduplication, observability และ retry awareness ค่อนข้างสูง

WebSocket คืออะไร

WebSocket คือการเปิด connection แบบสองทางระหว่าง client กับ server แล้วคง connection ไว้ เพื่อให้ทั้งสองฝั่งส่งข้อมูลหากันได้ต่อเนื่องโดยไม่ต้องเปิด HTTP request ใหม่ทุกครั้ง

มันเหมาะกับงานที่ลักษณะ interaction เป็น realtime หรือ quasi-realtime จริง เช่น

chat
collaborative editing
live dashboard
trading screen
multiplayer state sync
live admin console
notification stream ที่ latency สำคัญมาก

จุดสำคัญคือ WebSocket ไม่ใช่แค่ “เร็วกว่า polling” แต่มันเปลี่ยนรูปแบบการสื่อสารไปเลย จาก request-response เป็น persistent session

ข้อดีของ WebSocket

WebSocket เด่นมากเมื่อข้อมูลเปลี่ยนบ่อยและผู้ใช้ต้องเห็นเร็ว

ข้อดีหลักคือ

latency ต่ำ
server push ได้ทันที
รองรับ interaction สองทาง
ลด overhead ของการเปิด request ซ้ำ
เหมาะกับ UI ที่ต้อง update ต่อเนื่อง

ถ้างานของคุณเป็น live feed, chat, room presence หรือสถานะที่เปลี่ยนต่อเนื่อง WebSocket มักเหมาะกว่า polling มาก

ข้อเสียของ WebSocket

ข้อเสียคือมันซับซ้อนกว่าอย่างมีนัยสำคัญ

คุณต้องคิดเรื่อง

connection lifecycle
reconnect
auth ตอนเปิด socket และตอน token หมดอายุ
backpressure
scaling across instances
sticky sessions หรือ pub/sub backplane
monitoring จำนวน connection
message ordering
delivery guarantees
presence state

ดังนั้นถ้างานไม่ได้ต้อง realtime จริง หรือเป็นแค่การ “รอผลลัพธ์ async เป็นครั้งคราว” การกระโดดไปใช้ WebSocket อาจเกินความจำเป็น

สรุปความต่างแบบตรงไปตรงมา

ถ้าจะพูดแบบภาษาง่าย

Polling คือ “เดี๋ยวฉันคอยถามเอง”
Webhook คือ “มีอะไรเกิดขึ้นแล้วฉันจะโทรไปบอก”
WebSocket คือ “เราเปิดสายค้างไว้แล้วคุยกันตลอด”

ทั้งสามแบบไม่ใช่ศัตรูกัน และหลายระบบใช้ร่วมกันคนละจุดด้วยซ้ำ

ควรเลือกจากมุมไหนบ้าง

เวลาตัดสินใจในระบบจริง ลองดูจากมุมต่อไปนี้

1) ใครรู้ก่อนว่ามี event เกิดขึ้น

ถ้าต้นทางรู้ก่อนและปลายทางไม่ควรถามซ้ำเรื่อย ๆ webhook มักเหมาะกว่า

ถ้าปลายทางเป็นคนเดียวที่สนใจและถามเองได้ polling อาจง่ายกว่า

ถ้าเป็น session ระหว่าง user กับ server ที่ต้อง push กลับทันที WebSocket มักเหมาะกว่า

2) ต้อง realtime แค่ไหน

ถ้าหน่วงได้ 5–30 วินาที polling อาจพอ

ถ้าต้อง near-realtime เมื่อ event เกิด webhook มักดีกว่า polling

ถ้าต้อง interactive ต่อเนื่องระดับ sub-second หรือหลายครั้งต่อวินาที WebSocket จะเหมาะกว่า

3) ใครควบคุม infrastructure ได้มากกว่า

Webhook ต้องเปิด endpoint ให้รับจากภายนอก
ถ้าปลายทางอยู่หลัง firewall, private network หรือ callback กลับเข้ามายาก polling อาจง่ายกว่า

WebSocket ต้องให้ network path และ infra รองรับ connection ค้าง
ถ้า stack ปัจจุบันยังไม่พร้อม อาจยังไม่คุ้ม

4) delivery guarantee สำคัญแค่ไหน

Polling มีข้อดีตรงที่ถ้ารอบนี้พลาด รอบหน้าก็ถามใหม่ได้เอง
Webhook ต้องชัดเรื่อง retry, dedup และ verification
WebSocket ต้องชัดเรื่อง reconnect, missed messages และ state resync

5) scale pattern เป็นแบบไหน

ถ้ามีผู้ใช้จำนวนมากเปิดจอค้าง แต่ข้อมูลเปลี่ยนไม่ถี่ polling ถี่ ๆ อาจแพง
ถ้ามี event จาก provider กระจายเป็นช่วง ๆ webhook มักคุ้ม
ถ้ามี connection ค้างจำนวนมาก WebSocket ต้องมี infra รองรับจริง

ตัวอย่างงานที่เหมาะกับแต่ละแบบ

Polling เหมาะกับ

เช็กสถานะ report generation
เช็ก job status
dashboard ที่ update ทุก 15–60 วินาที
admin page ที่ดูค่าสถานะเป็นช่วง ๆ
client ที่อยู่ใน environment ปิดและไม่รับ callback ได้ง่าย

Webhook เหมาะกับ

payment event
external provider callback
CI/CD events
integration ระหว่างระบบ
async processing complete events
approval workflow บางแบบที่ action เกิดจากอีกระบบหนึ่ง

WebSocket เหมาะกับ

chat
live notification feed
room presence
realtime collaboration
live operational console
dashboard ที่เปลี่ยนถี่และต้องตอบสนองเร็วมาก

ความเข้าใจผิดที่เจอบ่อย

1) คิดว่า WebSocket ทันสมัยกว่าเลยควรใช้ก่อน

ไม่จริงเสมอไป

ถ้าคุณแค่ต้องเช็กสถานะงานทุก 10 วินาที WebSocket อาจทำให้ระบบซับซ้อนเกินเหตุ

2) คิดว่า webhook แทน polling ได้หมด

ไม่จริงเช่นกัน

Webhook เหมาะเมื่ออีกระบบพร้อมเป็นคนส่ง event มาให้ แต่ถ้าระบบต้นทางไม่มี webhook support หรือปลายทางรับ inbound traffic ไม่สะดวก polling อาจ practical กว่า

3) คิดว่า polling แปลว่าออกแบบไม่ดี

ไม่จริง

Polling ที่ออกแบบดีและเหมาะกับ latency requirement อาจเป็นคำตอบที่ดีที่สุดในหลายระบบ โดยเฉพาะเมื่องานไม่ต้อง realtime จริง

ความเสี่ยงเชิง production ของแต่ละแบบ

Polling

ความเสี่ยงหลักคือ load และ inefficiency
ต้องคิดเรื่อง interval, cache, conditional requests, backoff และ cost ของ query ให้ดี

Webhook

ความเสี่ยงหลักคือ trust และ delivery semantics
ต้องคิดเรื่อง signature verification, replay protection, dedup, retry handling, backlog และ auditability

WebSocket

ความเสี่ยงหลักคือ connection management และ distributed state
ต้องคิดเรื่อง reconnect, auth refresh, fan-out, scaling และ observability ของ long-lived connections

ตัวอย่างให้เห็นภาพ: payment flow

สมมติผู้ใช้กดจ่ายเงินผ่าน provider ภายนอก

ถ้าใช้ Polling

frontend เรียก GET /payments/{id} ทุก 5 วินาที
backend ไปดูสถานะล่าสุดแล้วตอบกลับ

ข้อดีคือ frontend คุม flow เองได้ง่าย
ข้อเสียคือมี request ซ้ำแม้ยังไม่มีอะไรเปลี่ยน

ถ้าใช้ Webhook

provider ส่ง event payment.succeeded มาที่ backend
backend อัปเดต order state
frontend อาจค่อย polling หรือ refresh state จาก backend อีกที

นี่เป็นแบบที่พบได้บ่อยใน production เพราะ event สำคัญมาจากระบบภายนอก และ backend เป็นจุดรวม state ที่เชื่อถือได้กว่า browser

ถ้าใช้ WebSocket

backend push สถานะใหม่ไปยัง browser ทันทีเมื่อได้รับ webhook

แบบนี้เหมาะเมื่อ UX ต้อง realtime มากขึ้น แต่จริง ๆ มักเป็นการใช้ webhook กับ WebSocket ร่วมกัน ไม่ใช่แทนกันตรง ๆ

หลายระบบใช้มากกว่าหนึ่งแบบพร้อมกัน

นี่คือจุดสำคัญมาก

ในโลกจริง คุณไม่จำเป็นต้องเลือกอย่างเดียวทั้งระบบ

ตัวอย่างเช่น

ใช้ webhook รับ event จาก payment provider
ใช้ WebSocket push status ไปยัง dashboard ภายใน
ใช้ polling เป็น fallback ถ้า browser reconnect ใหม่แล้วต้อง sync state

หรือ

ใช้ webhook เชื่อมกับ external systems
ใช้ polling สำหรับ admin pages ที่ไม่ได้ต้อง realtime มาก
ใช้ WebSocket กับห้องแชตหรือ live support เท่านั้น

การเลือกแบบผสมมัก practical กว่าการยึด pattern เดียวทั้งระบบ

ตัวอย่าง OpenAPI / HTTP มุมมองต่อ pattern เหล่านี้

OpenAPI อธิบาย request-response APIs ได้ดีมาก จึงเหมาะกับ polling และ webhook endpoints ที่ยังเป็น HTTP interactions ชัดเจน

เช่น

GET /jobs/{id}
POST /webhooks/provider

แต่สำหรับ WebSocket นั้น OpenAPI ไม่ได้เป็นตัวหลักในการอธิบาย protocol ทั้งหมดแบบเดียวกับ HTTP API ปกติ จึงอาจต้องใช้เอกสารเสริม หรือเครื่องมือเฉพาะด้าน event-driven / async protocols เพิ่ม

นี่เป็นอีกเหตุผลว่าทำไมถ้าระบบยังอิง HTTP interactions เป็นหลัก polling และ webhook มัก integrate เข้ากับ tooling ปัจจุบันได้ง่ายกว่า

ตัวอย่าง Express/Node.js แบบเริ่มต้น

ตัวอย่างนี้ไม่ได้พยายามสร้างทั้งสามแบบให้ครบ production-ready แต่สื่อให้เห็นรูปแบบการใช้งานเบื้องต้น

const express = require("express");
const app = express();

app.use(express.json());

let latestJobState = {
  id: "job_123",
  status: "processing",
  updatedAt: new Date().toISOString()
};

/**
 * Polling endpoint
 */
app.get("/jobs/:jobId", (req, res) => {
  return res.status(200).json(latestJobState);
});

/**
 * Webhook endpoint
 */
app.post("/webhooks/job-complete", (req, res) => {
  const { jobId, status } = req.body;

  if (!jobId || !status) {
    return res.status(400).json({
      error: "Invalid webhook payload"
    });
  }

  latestJobState = {
    id: jobId,
    status,
    updatedAt: new Date().toISOString()
  };

  return res.status(200).json({
    success: true
  });
});

/**
 * หมายเหตุ:
 * WebSocket จริงต้องใช้ library เช่น ws หรือ Socket.IO
 * และต้องออกแบบ auth, reconnect, fan-out และ scaling เพิ่ม
 */

app.listen(3000, () => {
  console.log("Server listening on port 3000");
});

ตัวอย่างนี้ช่วยให้เห็นภาพว่า polling กับ webhook ยังอยู่ในโลกของ HTTP request-response เหมือนกัน แต่ direction ของการเริ่มต้นต่างกัน

polling: client ถาม
webhook: server ต้นทางส่งมา

ส่วน WebSocket จะเป็นอีกโมเดลหนึ่งไปเลย

ถ้าจะเริ่มแบบปลอดภัย ควรคิดยังไง

ถ้าระบบยังเล็กหรือ requirement ยังไม่นิ่ง การเริ่มจากสิ่งที่ง่ายที่สุดที่ตอบโจทย์ได้ มักดีกว่ากระโดดไปใช้รูปแบบที่ซับซ้อนที่สุด

แนวคิดที่ใช้ได้จริงคือ

ถ้า delay ได้และอยากง่าย เริ่มจาก polling
ถ้า event มาจาก external system และไม่อยากถามซ้ำ ใช้ webhook
ถ้า UI ต้องสดจริงและมี interaction ต่อเนื่อง ใช้ WebSocket
ถ้ายังไม่แน่ใจ เริ่มจาก webhook หรือ polling แล้วค่อยเพิ่ม WebSocket เฉพาะจุดที่จำเป็น

จุดที่ต้องระวังใน production

ถ้าเลือก Polling

อย่าลืมคิดเรื่อง interval, caching, backoff และ query efficiency
ไม่อย่างนั้นสิ่งที่ดูง่ายจะค่อย ๆ กิน load แบบเงียบ ๆ

ถ้าเลือก Webhook

อย่าปล่อย endpoint โล่ง ๆ
ต้องมี verification, dedup, idempotent handling และ logging ที่ตามย้อนหลังได้

ถ้าเลือก WebSocket

อย่าคิดแค่เรื่อง “push ได้”
ต้องคิดต่อเรื่อง reconnect, session state, auth refresh, missed events และ horizontal scaling

รีวิวแนวทางนี้แบบ production-minded

Correctness

การเลือก pattern ให้ตรงกับธรรมชาติของงานช่วยลดการออกแบบ workaround ภายหลัง เช่นใช้ polling ถี่เกินเหตุเพื่อเลียนแบบ realtime หรือใช้ WebSocket กับงานที่จริง ๆ เป็นแค่ async status check

Security

Webhook ต้องระวัง verification มากที่สุด
WebSocket ต้องระวัง auth และ session lifecycle
Polling ต้องระวัง abuse และ rate limiting โดยเฉพาะ public endpoints

Efficiency

Polling เรียบง่ายแต่เปลืองถ้าตั้งถี่
Webhook efficient เมื่อ event-driven จริง
WebSocket คุ้มเมื่อมีการสื่อสารต่อเนื่องและ update ถี่

Error handling

Webhook ต้องออกแบบ retry และ dedup
Polling ต้องออกแบบ backoff และ error states
WebSocket ต้องออกแบบ reconnect และ state resync

Checklist สั้น ๆ ก่อนเลือก

ข้อมูลเปลี่ยนจากฝั่งไหนก่อน
ผู้ใช้ต้องเห็นเร็วแค่ไหน
มี external system เข้ามาเกี่ยวข้องหรือไม่
ปลายทางเปิดรับ inbound traffic ได้ไหม
ระบบต้องรองรับ retry และ dedup แบบไหน
connection ค้างจำนวนมากเป็นปัญหาไหม
ทีมมี tooling และ observability สำหรับ pattern นี้หรือยัง
ถ้าข้อความตกหล่น จะ recover ยังไง
ถ้า pattern นี้ fail มี fallback ไหม
ใช้แบบผสมจะง่ายกว่าหรือไม่

บทความที่ควรอ่านต่อ

สรุป

Webhook, polling และ WebSocket ไม่ได้แข่งกันว่าใครดีกว่าเสมอไป แต่ตอบโจทย์คนละแบบ

polling เด่นที่ความง่าย
webhook เด่นที่ความเป็น event-driven
WebSocket เด่นที่การสื่อสารต่อเนื่องแบบ realtime

ดังนั้นคำตอบที่ดีในระบบจริงมักไม่ได้เริ่มจากคำว่า “อันไหนทันสมัยกว่า” แต่เริ่มจากคำถามว่า “ระบบนี้ต้องรับรู้การเปลี่ยนแปลงแบบไหน และทีมพร้อมดูแล complexity ระดับใด”

สรุปสั้นที่สุดคือ

เลือก pattern ตามธรรมชาติของ event, latency ที่ยอมรับได้ และต้นทุน operation ที่ทีมรับไหว