Appearance
10.05 Retry & Recovery Strategy
📌 At a Glance
| รายการ | รายละเอียด |
|---|---|
| Topic | Retry & Recovery Strategy |
| Difficulty | ⭐⭐ Intermediate |
| Reading Time | 10 นาที |
| Target | Developer, System Integrator |
| Related APIs | All APIs |
🎯 Learning Objectives
หลังจากศึกษาหัวข้อนี้แล้ว ผู้อ่านจะสามารถ
- ออกแบบกลไก Retry ที่เหมาะสมสำหรับ SISAHYGO API
- แยกแยะข้อผิดพลาดที่ควร Retry และไม่ควร Retry
- วางแนวทาง Recovery เมื่อเกิดความผิดพลาดระหว่างการเชื่อมต่อ
- ลดผลกระทบจาก Network Error และ Server Error ในระบบ Production
Overview
ในสภาพแวดล้อมการใช้งานจริง การสื่อสารระหว่าง Client System และ SISAHYGO API อาจได้รับผลกระทบจากปัจจัยต่าง ๆ เช่น ความหน่วงของเครือข่าย การเชื่อมต่อที่ไม่เสถียร หรือการหยุดให้บริการชั่วคราวของระบบ
เพื่อให้ระบบสามารถทำงานได้อย่างต่อเนื่อง Client System ควรมี Retry Strategy และ Recovery Process ที่เหมาะสม โดยไม่ส่งผลให้เกิดข้อมูลซ้ำหรือภาระที่ไม่จำเป็นต่อ API Server
Figure 10-5 Retry & Recovery Strategy
Figure 10-5 แสดงแนวทางการจัดการเมื่อการเรียก API ล้มเหลว ตั้งแต่การวิเคราะห์ประเภทของข้อผิดพลาด การตัดสินใจ Retry การบันทึกเหตุการณ์ และการกู้คืนกระบวนการทำงาน
Retry Workflow
text
Send API Request
│
▼
Receive Response
│
▼
Success ?
│
├────────► Yes
│
▼
Continue Process
│
└────────► No
│
▼
Check HTTP Status
│
├────────► 4xx
│
▼
Correct Request
│
▼
Submit Again
│
└────────► 5xx / Network
│
▼
Retry Strategy
│
▼
Exponential Backoff
│
▼
Retry Success ?
│
├────────► Yes
│
▼
Continue Process
│
└────────► No
│
▼
Log & NotifyRecommended Retry Policy
| HTTP Status | Retry | Recommendation |
|---|---|---|
| 200 | ❌ | Success |
| 201 | ❌ | Success |
| 400 | ❌ | ตรวจสอบ Request |
| 401 | ❌ | ตรวจสอบ API Key |
| 403 | ❌ | ตรวจสอบสิทธิ์ |
| 404 | ❌ | ตรวจสอบ Endpoint หรือ Resource |
| 422 | ❌ | แก้ไขข้อมูลก่อนส่งใหม่ |
| 429 | ✅ | Retry พร้อมหน่วงเวลา |
| 500 | ✅ | Retry |
| 503 | ✅ | Retry |
Exponential Backoff
สำหรับข้อผิดพลาดที่สามารถ Retry ได้ แนะนำให้ใช้ Exponential Backoff
ตัวอย่าง
| Attempt | Delay |
|---|---|
| 1 | 2 วินาที |
| 2 | 4 วินาที |
| 3 | 8 วินาที |
| 4 | 16 วินาที |
| 5 | 32 วินาที |
ควรกำหนดจำนวนครั้งสูงสุดของการ Retry เพื่อป้องกันการเรียก API ซ้ำไม่สิ้นสุด
Recovery Strategy
หาก Retry ไม่สำเร็จ
- บันทึกเหตุการณ์ลง Error Log
- แจ้งเตือนผู้ดูแลระบบ (ถ้ามี)
- เก็บรายการไว้ใน Queue หรือ Pending List
- เปิดโอกาสให้ระบบส่งใหม่ภายหลัง
- หลีกเลี่ยงการสร้างข้อมูลซ้ำ
Queue-Based Recovery
สำหรับระบบที่มีปริมาณข้อมูลจำนวนมาก แนะนำให้ใช้ Queue
text
Business System
│
▼
Pending Queue
│
▼
Retry Worker
│
▼
SISAHYGO API
│
▼
Success
or
Retry LaterIdempotency Considerations
Client System ควรใช้
client_reference_no
เป็นเลขอ้างอิงหลักในการติดตามรายการ
หากเกิดการ Retry หลังจาก Network Timeout ระบบสามารถตรวจสอบได้ว่ารายการเดิมถูกสร้างแล้วหรือไม่ เพื่อลดโอกาสการส่งข้อมูลซ้ำ
Common Recovery Scenarios
| Scenario | Recommended Action |
|---|---|
| Network Timeout | Retry |
| HTTP 500 | Retry |
| HTTP 503 | Retry |
| HTTP 429 | Retry หลังหน่วงเวลา |
| Validation Error | แก้ไขข้อมูลก่อนส่งใหม่ |
| Authentication Error | ตรวจสอบ API Key |
| Business Rule Error | ตรวจสอบข้อมูลและกระบวนการ |
Best Practices
- ใช้ Exponential Backoff แทน Retry ทันที
- จำกัดจำนวนครั้งของการ Retry
- ใช้ Queue สำหรับ Retry แบบอัตโนมัติ
- บันทึกทุกเหตุการณ์ที่ Retry
- ใช้
client_reference_noเพื่อป้องกันการสร้างรายการซ้ำ - แยก Retry Logic ออกจาก Business Logic
Related Sections
- 09.06 Error Handling Best Practices
- 10.04 Caching Strategy
- 10.06 Logging & Monitoring
Summary
Retry & Recovery Strategy เป็นองค์ประกอบสำคัญของระบบ Integration ในระดับ Production โดยควร Retry เฉพาะข้อผิดพลาดที่สามารถกู้คืนได้ เช่น Network Error หรือ Server Error และหลีกเลี่ยงการ Retry สำหรับ Validation หรือ Authentication Errors การใช้ Exponential Backoff, Queue-Based Recovery และการอ้างอิงด้วย client_reference_no จะช่วยให้ระบบมีความเสถียร ลดโอกาสการสร้างข้อมูลซ้ำ และสามารถทำงานต่อได้แม้เกิดปัญหาชั่วคราว
Next Step
➡️ 10.06 Logging & Monitoring