Rate Limits & Quotas

การส่งข้อความถูกจำกัดอัตราต่อ tenant และต่อ queue โดย traffic ประเภท transactional และ broadcast จะถูกนับแยกกัน ดังนั้นการส่ง broadcast จำนวนมากจึงไม่บริโภค quota ของ transactional

ออกแบบระบบให้รองรับ throttling

• รวมเป็น batch ภายใน request เดียว endpoint การส่งแต่ละตัวรับ array ใน data (ปัจจุบันสูงสุด 100 รายการ) — ควรส่ง 1 ครั้งที่มีหลายรายการแทนการส่งหลายครั้งแบบรายการเดียว
• Backoff เมื่อได้รับ 429 ให้ถือว่า rate-limit response เป็นเหตุการณ์ชั่วคราว retry ด้วย exponential backoff และ jitter โดยจำกัดไม่เกิน ~5 ครั้ง
• ทำให้ retry เป็น idempotent ใช้ transaction_uuid เดิมเมื่อ retry เพื่อป้องกันการส่งซ้ำ

async function sendWithRetry(body: unknown, attempt = 0): Promise<Response> {
  const res = await fetch(`${ME_BASE}/sms/send_messages/message`, {
    method: "POST",
    headers: {
      "X-Token": ME_TOKEN,
      "X-TenantID": ME_TENANT,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  });
  if (res.status === 429 && attempt < 5) {
    const wait = Math.min(2 ** attempt * 250, 8000) + Math.random() * 250;
    await new Promise((r) => setTimeout(r, wait));
    return sendWithRetry(body, attempt + 1);
  }
  return res;
}

อย่า retry แบบวนซ้ำทันที

การ retry ทันทีเมื่อได้รับ 429 จะยิ่งทำให้ throttling แย่ลง ควรรอและเพิ่ม jitter เสมอ เพื่อป้องกัน client หลาย ๆ ตัว retry พร้อมกัน

การจัดกำหนดการช่วยกระจาย spike

สำหรับการส่งจำนวนมากที่มีเวลาเป้าหมายในอนาคต ให้กำหนด digest และปล่อยให้ platform กระจายการส่งแทนที่จะยิงทุกอย่างพร้อมกัน หากต้องการยกเลิกก่อนการส่งออก ให้ใช้ GET /sms/broadcast/{batchId} เพื่อดูสถานะ batch