ทีม 2 คนมอนิเตอร์ DM และ Mention บน X ให้ลูกค้า 4 ราย — โดยไม่ต้องจ่ายค่าอ่าน API ต่อครั้ง — UnifyPort

มกราคม 2026 เอเจนซีโซเชียลมีเดีย 2 คนในลิสบอนดูแลบัญชี X (Twitter) ให้ลูกค้า 4 ราย — แบรนด์อีคอมเมิร์ซ 2 ราย สตาร์ทอัพ SaaS 1 ราย และเชนร้านอาหารท้องถิ่น 1 ราย งานตรงไปตรงมา: มอนิเตอร์ DM และ mention ในแต่ละบัญชี ตอบภายในไม่กี่ชั่วโมง ส่งต่อสิ่งที่ต้องให้ลูกค้าจัดการเอง เทคโนโลยีก็เรียบง่าย: เซอร์วิส Node.js polling API ของ X ทุก 30 วินาทีต่อบัญชี ตรวจสอบกิจกรรมใหม่ แล้วส่งข้อความไปยังช่อง Slack ที่ใช้ร่วมกันเพื่อคัดกรอง

ภายใต้ราคาเดิมของ X — แพ็กเกจรายเดือนแบบคงที่ที่ใช้มาตั้งแต่ปี 2023 — ระบบนี้มีค่าใช้จ่าย $100/เดือน ที่แพ็กเกจ Basic คาดเดาได้ จัดงบได้ง่าย และรวมอยู่ในค่า retainer ที่ลูกค้าจ่ายอยู่แล้ว

แล้วเดือนกุมภาพันธ์ก็มาถึง

มิเตอร์เริ่มวิ่ง

3 กุมภาพันธ์ 2026 X เปลี่ยนจากราคาแพ็กเกจคงที่เป็นคิดค่าบริการต่อครั้ง ทุกการเรียก API — ทั้งอ่านและเขียน — มีราคาต่อ request สถาปัตยกรรม polling ที่ออกแบบมาสำหรับโลกที่เรียก API ได้ไม่จำกัดในแพ็กเกจ กลายเป็นมิเตอร์ที่วิ่งตลอดเวลาในชั่วข้ามคืน

ตัวเลขชัดเจนทันที บัญชีลูกค้า 4 บัญชี แต่ละบัญชี polling ทุก 30 วินาทีเพื่อตรวจ DM และ mention นั่นคือ 8 ครั้งอ่านต่อนาที (2 endpoint ต่อบัญชี × 4 บัญชี) หรือ 11,520 ครั้งต่อวัน หรือประมาณ 345,600 ครั้งต่อเดือน — แค่ค่ามอนิเตอร์อย่างเดียว ยังไม่ได้รับข้อความสักข้อความ

20 เมษายน X ปรับอัตราค่าบริการ: อ่านทรัพยากรของตัวเองลดเหลือ $0.001 ต่อครั้ง — ค่าอ่านมอนิเตอร์รายเดือนลดเหลือประมาณ $346 แต่การปรับเดียวกันนี้ขึ้นค่าเขียน (ตอบกลับ) จาก $0.010 เป็น $0.015 เอเจนซีส่งประมาณ 400–600 การตอบกลับต่อเดือนรวมทุกบัญชี คิดที่ $0.015 เพิ่มขึ้น $6–$9 ตัวเลขเดี่ยวๆ ไม่มาก แต่แนวโน้มน่ากังวล: ทุกบัญชีลูกค้าใหม่เพิ่ม polling loop หนึ่งวง ทุกการตอบกลับเพิ่มดันบิลจากทั้งสองด้าน

สิ่งที่แพงจริงไม่ใช่อัตราค่าบริการ — แต่เป็นสถาปัตยกรรม

ผู้ก่อตั้งเอเจนซีคำนวณตัวเลขสำหรับ Q3 สมมติ: ถ้ารับลูกค้าเพิ่มอีก 2 ราย (เป็นไปได้จริงตาม pipeline ปัจจุบัน) แค่ polling reads ก็จะเพิ่มเป็นสองเท่าโดยประมาณ ราคาต่อครั้งต่ำจริง แต่ปริมาณเป็นเชิงโครงสร้าง — ขึ้นอยู่กับความถี่ที่เซอร์วิสตรวจสอบข้อความใหม่ ไม่ใช่จำนวนข้อความที่เข้ามาจริง วันอาทิตย์เงียบๆ ไม่มี DM สักข้อความ polling loop ก็วิ่งเร็วเท่าเดิมและค่าใช้จ่ายเท่ากับวันเปิดตัวสินค้า

นี่คือส่วนของโมเดลคิดค่าบริการต่อครั้งของ X ที่บทความเปรียบเทียบราคาไม่ได้บอก: ต้นทุนของการรอข้อความไม่ใช่ศูนย์ และมัน scale ตามสถาปัตยกรรมการมอนิเตอร์ ไม่ใช่ตามปริมาณข้อความจริง Polling สี่บัญชีทุก 30 วินาที หมายถึง 345,600 ครั้งอ่านต่อเดือน ไม่ว่าจะได้รับ 10 หรือ 10,000 ข้อความ

ลด polling interval เป็นทางแก้ที่ชัดเจนที่สุด เอเจนซีลอง 2 นาทีต่อครั้งเป็นเวลาหนึ่งสัปดาห์ เวลาตอบกลับลดลงอย่างเห็นได้ชัด — DM อาจนั่งรอเกือบ 4 นาทีในกรณีเลวร้ายที่สุด และลูกค้าสองรายระบุ SLA “ตอบภายใน 2 ชั่วโมง” ในสัญญา ความล่าช้าไม่ผิด SLA แต่ความรู้สึกของบริการเปลี่ยนจาก “เกือบเรียลไทม์” เป็น “สักพักจะเห็น” สามวันหลังจากนั้นพวกเขาเปลี่ยนกลับ

เปลี่ยนจาก pull เป็น push

ทางแก้ที่ถูกต้องไม่ใช่ optimize polling — แต่คือกำจัด polling ออกไป เอเจนซีเชื่อมต่อบัญชี X ของลูกค้าทั้งสี่รายเข้ากับ UnifyPort ซึ่ง push DM และ mention ไปยัง webhook ทันทีที่ข้อความมาถึง ไม่มี polling loop ไม่มีค่าอ่านต่อครั้ง ไม่มีต้นทุนที่ scale ตามความถี่ในการตรวจสอบ

การเปลี่ยนสถาปัตยกรรมมีลักษณะดังนี้:

ก่อน (polling):
  เซอร์วิส ──► X API (อ่าน DM)      ×4 บัญชี ×2/นาที = 345,600 reads/เดือน
  เซอร์วิส ──► X API (อ่าน mention)  ×4 บัญชี ×2/นาที = 345,600 reads/เดือน
  รวม: ~691,200 API reads ที่คิดค่าบริการ/เดือน

หลัง (webhook push):
  บัญชี X ──► UnifyPort ──► POST /webhook ──► Slack (ลูกค้า A)
  บัญชี X ──► UnifyPort ──► POST /webhook ──► Slack (ลูกค้า B)
  บัญชี X ──► UnifyPort ──► POST /webhook ──► Slack (ลูกค้า C)
  บัญชี X ──► UnifyPort ──► POST /webhook ──► Slack (ลูกค้า D)
  รวม: 0 X API reads

ข้อความขาเข้าของแต่ละบัญชีถูกส่งเป็น event message.received — payload ที่ normalize แล้วเหมือนกับที่เอเจนซีจะได้รับหากต่อ WhatsApp หรือ LINE สำหรับลูกค้ากลุ่มเดียวกันในภายหลัง:

{
  "event": "message.received",
  "account_id": "acct_client_a",
  "provider": "twitter",
  "from": "user_7d2e1f",
  "text": "Hey, is the summer sale still on? Saw a post but the link was broken",
  "timestamp": 1750320000,
  "message_id": "x_msg_8a3b2c"
}

Webhook handler ตรวจสอบแต่ละการส่งด้วย HMAC-SHA256 จากนั้น route ตาม account_id ไปยังช่อง Slack ของลูกค้าที่ถูกต้อง:

app.post("/webhook", (req, res) => {
  if (!verifySignature(req)) return res.sendStatus(401);

  const evt = req.body;
  if (evt.event === "message.received") {
    const channel = clientChannelMap[evt.account_id];
    slack.postMessage(channel, {
      text: `[${evt.provider}] ${evt.from}: ${evt.text}`,
      metadata: { messageId: evt.message_id },
    });
  }
  res.sendStatus(200);
});

สี่บัญชี หนึ่ง endpoint หนึ่ง signing secret เซอร์วิส polling ปิดตัวลงทั้งหมด

อะไรเปลี่ยน

ค่า X API ของเอเจนซีลดจาก ~$350/เดือน (และเพิ่มขึ้นตามลูกค้าใหม่) เป็น reads ที่คิดค่าบริการเท่ากับศูนย์ Latency การตอบกลับยังดีขึ้นด้วย — event มาถึงภายในไม่กี่วินาทีหลังข้อความถูกส่ง แทนที่จะรอ polling cycle ถัดไป การเพิ่มบัญชีลูกค้าใหม่ไม่ได้หมายถึงเพิ่ม polling loop ในบิลอีกต่อไป — แค่เพิ่มอีกบรรทัดใน clientChannelMap

ทีมสองคนยังตอบ DM และ mention บน X แบบเดิม — จาก Slack ผ่าน reply endpoint ที่ route กลับผ่าน UnifyPort สิ่งที่เปลี่ยนคือ “มอนิเตอร์สี่บัญชี X” ไม่ใช่ต้นทุน API ที่ต้อง model ต้องอธิบายให้ลูกค้า หรือต้องกังวลเรื่อง scaling อีกต่อไป ถ้า Q3 pipeline มีอีก 2 บัญชีเข้ามา webhook รับ 6 แทน 4 บิลไม่รู้ความแตกต่าง

สำหรับเอเจนซีและทีมที่จัดการหลายบัญชี X — โดยเฉพาะทีมที่ ค่า X API scale ตามความถี่ polling ไม่ใช่ตามปริมาณข้อความ — คำถามเชิงสถาปัตยกรรมไม่ใช่ “polling interval เท่าไหร่ถูกที่สุด” แต่คือเมื่อ push-based webhook สามารถส่งข้อความเดียวกันได้โดยไม่ต้องเปิดมิเตอร์ โมเดล pull ยังจำเป็นอยู่หรือไม่