ระบบส่งงานเจอ 429 ควรรอเท่าไร และเมื่อไรต้องหยุดลองซ้ำ
ส่งบ่อยขึ้นอาจทำให้ฟื้นช้าลง
เมื่อระบบอัตโนมัติส่งงานแล้วพบ HTTP 429 อย่าตั้งให้ยิงซ้ำทันทีไปเรื่อย ๆ โดยทั่วไปสัญญาณนี้หมายถึงส่งคำขอมากเกินข้อจำกัดของบริการ ควรอ่านเงื่อนไข API และเวลาที่ปลายทางแนะนำให้รอ แล้วกำหนดทั้งจำนวนครั้งและเวลารวมที่ยอมให้ลอง งานที่รอไม่ได้ต้องมีคนรับช่วง ไม่ใช่ซ่อนอยู่ในคิวโดยไม่มีกำหนด
Microsoft แนะนำให้แยกความผิดพลาดชั่วคราวออกจากปัญหาที่ลองใหม่ก็ไม่หาย เช่น ข้อมูลไม่ถูกต้องหรือไม่มีสิทธิ์ การออกแบบจึงเริ่มจากตารางรหัสและความหมายของบริการจริง ไม่ใช้กฎว่าทุกคำตอบที่ไม่สำเร็จต้องส่งใหม่
กำหนดจังหวะและเพดานร่วมกัน
หากคำตอบมี Retry-After ให้ทีมเทคนิคอ่านค่าตามข้อกำหนดของบริการและรออย่างน้อยตามที่ระบุ หากไม่มี ให้ใช้นโยบายที่เพิ่มช่วงรอและกระจายเวลาเริ่มใหม่ เพื่อลดการที่หลายเครื่องกลับมาส่งพร้อมกัน ไม่ควรคัดจำนวนวินาทีจากระบบอื่นโดยไม่ทดสอบกับโหลดจริง
ตรวจว่ามีการลองซ้ำอยู่แล้วในเครื่องมือเชื่อมต่อหรือไลบรารีหรือไม่ ตัวอย่างสมมติ ชั้นนอกส่ง 3 ครั้งและแต่ละครั้งชั้นในส่งได้ 3 ครั้ง อาจกลายเป็นคำขอ 9 ครั้ง จึงควรระบุว่าใครเป็นเจ้าของนโยบายและนับจำนวนคำขอที่ออกจริง ไม่ดูเฉพาะตัวเลขบนหน้าตั้งค่าชั้นเดียว
แยกงานไม่สำเร็จออกจากงานไม่ทราบผล
เมื่อหมดเวลารอคำตอบ อาจยังไม่รู้ว่าปลายทางบันทึกแล้วหรือยัง ก่อนส่งคำสั่งที่สร้างผลทางธุรกิจซ้ำ ต้องตรวจสถานะด้วยรหัสงานเดิมหรือกลไกป้องกันผลซ้ำของระบบ การรอนานขึ้นแก้ปัญหาโหลดได้บางส่วน แต่ไม่ได้ป้องกันใบสั่งซื้อหรือการชำระซ้ำด้วยตัวเอง
เมื่อถึงเพดาน ให้เก็บงานไว้ในสถานะรอตรวจพร้อมเหตุผล เวลาล่าสุด จำนวนครั้ง และผู้รับผิดชอบ การกดส่งใหม่โดยผู้ดูแลต้องมีบันทึกและตรวจว่าข้อมูลยังใช้ได้ เช่น งานเก่าที่ถูกยกเลิกแล้วไม่ควรถูกส่งกลับเพราะระบบเพิ่งฟื้น หลีกเลี่ยงใส่ข้อมูลลับทั้งฉบับในข้อความแจ้งเตือน
ทดสอบให้เห็นการหยุดและการกลับมาทำงาน
ในระบบทดสอบ จำลอง 429 ที่มีและไม่มีเวลารอ จำลองข้อมูลผิด จำลองคำตอบหายหลังบันทึก และจำลองบริการล่มนานกว่าเพดาน ตรวจจำนวนคำขอจริง ระยะเวลาค้าง และผลธุรกิจที่เกิด ไม่เพียงตรวจว่าในที่สุดหน้าจอขึ้นสีเขียว หากงานใหม่โดนงานเก่าขวาง ต้องออกแบบการจัดคิวเพิ่ม
ก่อนให้ Chawinnix วางระบบอัตโนมัติ ให้เจ้าของงานระบุเวลาที่ธุรกิจรอได้ ผู้รับช่วง และสิ่งที่ห้ามเกิดซ้ำ แล้วให้ทีมเทคนิคเสนอวิธีตรวจผลและหยุดส่งตามขอบเขตจริง นโยบาย retry ที่ดีควรอธิบายได้ทั้งเมื่อบริการฟื้นและเมื่อบริการยังไม่ฟื้น
