เวลาพูดถึงการเชื่อมต่อระบบสองตัวเข้าหากัน ไม่ว่าจะเป็น payment gateway กับระบบบัญชี, ERP กับ e-commerce, หรือ CRM กับ marketing tool — คำถามที่นักพัฒนาและ IT manager ต้องตอบคือ:
"เราจะรู้ได้ยังไงว่ามีข้อมูลใหม่ให้ sync?"
คำตอบมีสองแนวทางหลัก: Polling และ Webhook สองวิธีนี้ต่างกันพื้นฐาน และการเลือกผิดอาจทำให้ระบบช้า แพง หรือซับซ้อนโดยไม่จำเป็น
Polling คืออะไร?
Polling คือการที่ระบบฝั่งคุณ "ถามซ้ำๆ" server ปลายทางว่ามีข้อมูลใหม่หรือยัง เปรียบเหมือนการโทรถามร้านอาหารทุก 5 นาทีว่า "โต๊ะว่างหรือยัง?"
How it works:
Client → GET /orders?updated_after=2026-03-27T10:00:00 → Server
Client ← { orders: [] } ← Server (ยัง ไม่มีใหม่)
... 5 นาทีต่อมา ...
Client → GET /orders?updated_after=2026-03-27T10:00:00 → Server
Client ← { orders: [{ id: 123, status: "paid" }] } ← Server
ข้อดีของ Polling:
- ง่ายต่อการ implement — แค่ loop + API call
- Client ควบคุม timing เอง
- ไม่ต้องมี public URL ให้ server เรียก
- ทดสอบง่าย
ข้อเสียของ Polling:
- สิ้นเปลือง resource — ส่วนใหญ่ response จะว่างเปล่า
- Latency สูง — ข้อมูลใหม่อาจรอนานถึง interval ถัดไป
- ถ้า interval สั้นเกินไป อาจ hit rate limit ของ API
Webhook คืออะไร?
Webhook คือการที่ server ปลายทาง "แจ้งเตือน" ระบบของคุณเองทันทีเมื่อมี event เกิดขึ้น โดยที่คุณไม่ต้องถามก่อน เปรียบเหมือนการฝากหมายเลขโทรศัพท์ไว้กับร้าน และร้านจะโทรหาคุณเองเมื่อโต๊ะว่าง
How it works:
1. คุณลงทะเบียน URL: POST /register-webhook { url: "https://your-app.com/hooks/payment" }
2. เมื่อ payment สำเร็จ:
Server → POST https://your-app.com/hooks/payment → คุณ
Body: { event: "payment.completed", orderId: "123", amount: 5000 }
3. ระบบของคุณ process ทันที
ข้อดีของ Webhook:
- Real-time — ข้อมูลมาทันทีเมื่อ event เกิด
- ประหยัด resource — ไม่มี wasted request
- Scale ได้ดีกว่าสำหรับ high-volume events
ข้อเสียของ Webhook:
- ต้องมี public URL ที่ server เรียกได้ (ต้องมี HTTPS, งั้น local dev ยุ่งยากขึ้น)
- จัดการ failure ยากกว่า — ถ้าระบบล่ม อาจพลาด event
- ต้อง verify signature เพื่อความปลอดภัย
- Debug ยากกว่า polling
เปรียบเทียบ Webhook vs Polling
| หัวข้อ | Webhook | Polling |
|---|---|---|
| Latency | ต่ำมาก (milliseconds) | สูงกว่า (ขึ้นกับ interval) |
| Resource usage | ต่ำ | สูง (request ซ้ำ) |
| ความซับซ้อน | ปานกลาง (ต้องจัดการ endpoint) | ต่ำ (แค่ loop) |
| Real-time | ใช่ | ไม่ (approximate) |
| ความเหมาะสม | Event-driven workflows | Simple/batch sync |
| ต้องการ public URL | ใช่ | ไม่ |
| จัดการ failure | ซับซ้อนกว่า | ง่ายกว่า |
Use Cases: เลือกแบบไหน?
ใช้ Webhook เมื่อ:
- Payment confirmation — ต้องรู้ทันทีว่าลูกค้าจ่ายเงินแล้ว เพื่อ fulfill order
- Inventory change — สต็อกเปลี่ยนแปลงต้องอัปเดตทุก channel แบบ real-time
- Status updates — เช่น การส่งของ, K status จาก logistics partner
- User-triggered events — form submission, message หรือ comment ใหม่
ใช้ Polling เมื่อ:
- Batch sync รายคืน — ดึงข้อมูลขาย/order ของวันไปสร้างรายงาน
- API provider ไม่รองรับ Webhook — บางระบบเก่ามีแค่ REST API
- Internal tools ที่ไม่ต้องการ real-time — dashboard ที่ refresh ทุก 15 นาที
- Development/testing — ง่ายกว่าในการ debug
Best Practices สำหรับ Webhook
1. ตอบ 200 OK ให้เร็ว
Webhook endpoint ควรรับข้อมูล → บันทึก queue → ตอบ 200 ทันที แล้วค่อย process ในภายหลัง ถ้าประมวลผลนานเกินไปก่อนตอบ provider อาจ timeout และส่งซ้ำ
2. Verify Signature
Provider ส่วนใหญ่จะแนบ HMAC signature มาใน header ตรวจสอบก่อนเสมอเพื่อป้องกัน spoofed requests:
const signature = request.headers['x-stripe-signature']
const isValid = verifyStripeSignature(body, signature, process.env.WEBHOOK_SECRET)
if (!isValid) return res.status(401).send('Invalid signature')
3. Implement Idempotency
Provider อาจส่ง webhook event ซ้ำ (retry) ระบบต้องรองรับการ process event เดิมหลายครั้งโดยไม่เกิด side effects ใช้ eventId เป็น unique key ในการ deduplication
4. Log ทุก Incoming Event
บันทึก raw payload ของทุก webhook ที่ได้รับ ช่วยมากเวลา debug
Hybrid Approach: ใช้ทั้งสองวิธี
ในระบบ production จริง มักใช้ทั้ง Webhook และ Polling ร่วมกัน:
- Webhook สำหรับ real-time updates ปกติ
- Polling เป็น fallback ทุก 15–30 นาที เพื่อ catch missed events ที่เกิดจากระบบล่ม
สถาปัตยกรรมนี้ทำให้ระบบทั้ง responsive และ reliable
สรุป
ไม่มีคำตอบที่ถูกเสมอไปสำหรับการเลือกระหว่าง Webhook กับ Polling — มันขึ้นอยู่กับ use case, ความต้องการ latency, และความซับซ้อนที่คุณยอมรับได้
หากต้องการ real-time และระบบปลายทางรองรับ → Webhook คือคำตอบ หากต้องการความเรียบง่ายหรือ API ไม่รองรับ Webhook → Polling ก็ยังมีที่ยืน
ทีม Adowbig ช่วยออกแบบและ implement integration ระหว่างระบบได้ทุกประเภท ตั้งแต่ payment gateway ไปจนถึง ERP และ third-party platforms
