10.04 Caching Strategy

---

📌 At a Glance

รายการ	รายละเอียด
Topic	Caching Strategy
Difficulty	⭐⭐ Intermediate
Reading Time	10 นาที
Target	Developer, System Integrator
Related APIs	Master Data APIs, Shipment Tracking APIs

---

🎯 Learning Objectives

หลังจากศึกษาหัวข้อนี้แล้ว ผู้อ่านจะสามารถ

• เข้าใจหลักการใช้ Cache ในระบบ Integration
• เลือกข้อมูลที่เหมาะสมสำหรับการจัดเก็บใน Cache
• ลดจำนวน API Calls ที่ไม่จำเป็น
• เพิ่มประสิทธิภาพของ Client System และลดภาระของ API Server

---

Overview

การใช้ Cache เป็นแนวทางสำคัญในการพัฒนาระบบ Integration ระดับ Production โดยช่วยลดเวลาในการตอบสนอง ลดปริมาณการเรียก API และเพิ่มความสามารถในการรองรับผู้ใช้งานจำนวนมาก

อย่างไรก็ตาม ข้อมูลแต่ละประเภทมีลักษณะการเปลี่ยนแปลงแตกต่างกัน จึงควรกำหนดกลยุทธ์การจัดเก็บข้อมูลให้เหมาะสม

SISAHYGO แนะนำให้ใช้ Cache ร่วมกับฐานข้อมูลภายในของ Client System สำหรับข้อมูลที่เปลี่ยนแปลงไม่บ่อย และเรียก API โดยตรงเฉพาะข้อมูลที่ต้องการความเป็นปัจจุบัน

---

Figure 10-4 Caching Strategy

Figure 10-4 แสดงแนวทางการใช้ Cache ร่วมกับ Local Database เพื่อลดจำนวน API Calls และเพิ่มประสิทธิภาพของระบบ Integration

---

Recommended Cache Architecture

              SISAHYGO API

                    │

                    ▼

          Synchronization Service

                    │

        ┌───────────┴───────────┐

        ▼                       ▼

   Local Database          In-Memory Cache

        │                       │

        └───────────┬───────────┘

                    ▼

            Business Application

---

Cache Recommendations

Data	Cache	Recommendation
Receivers	✅	Cache และ Synchronize เป็นประจำ
Products	✅	Cache และ Synchronize เป็นประจำ
Units	✅	Cache และ Synchronize เมื่อข้อมูลเปลี่ยน
API Profile	✅	Cache ระหว่างการทำงานของระบบ
Shipment Tracking	❌	เรียก API โดยตรงเพื่อรับข้อมูลล่าสุด
Order Rejections	❌	เรียก API โดยตรงตามรอบเวลาที่กำหนด

---

Suggested Cache Duration

Data	Suggested Duration
Receivers	24 ชั่วโมง
Products	24 ชั่วโมง
Units	24 ชั่วโมง
Profile	จนกว่าจะมีการเปลี่ยน API Key หรือเริ่มต้นระบบใหม่
Shipment Tracking	ไม่ควร Cache
Order Rejections	ไม่ควร Cache

ระยะเวลาที่แนะนำเป็นเพียงแนวทาง สามารถปรับให้เหมาะสมกับลักษณะการใช้งานของแต่ละองค์กร

---

Cache Workflow

Application Request

        │

        ▼

Check Cache

        │

   ┌────┴────┐

   │         │

Hit        Miss

   │         │

   ▼         ▼

Return    Read Local DB

              │

              ▼

       Synchronize API

              │

              ▼

        Update Cache

              │

              ▼

        Return Result

---

Cache Invalidation

ควรล้างหรืออัปเดต Cache เมื่อ

• มีการ Synchronize Master Data
• เปลี่ยน API Key
• เปลี่ยน Customer ที่เชื่อมต่อ
• ผู้ดูแลระบบสั่ง Refresh ข้อมูล
• ตรวจพบข้อมูลไม่ตรงกับระบบต้นทาง

---

Benefits of Caching

Benefit	Description
Performance	ลดเวลาในการตอบสนอง
Scalability	รองรับผู้ใช้งานจำนวนมาก
Reduced API Calls	ลดภาระของ API Server
Better User Experience	ค้นหาข้อมูลได้รวดเร็ว
Offline Resilience	ใช้งานข้อมูลอ้างอิงได้ แม้ API ตอบสนองช้าชั่วคราว

---

Common Mistakes

Problem	Recommendation
Cache Shipment Status	ควรเรียก API โดยตรง
ไม่ Refresh Master Data	ตั้ง Scheduled Synchronization
Cache นานเกินไป	กำหนดอายุของข้อมูลให้เหมาะสม
ไม่มี Manual Refresh	เพิ่มเมนู Refresh สำหรับผู้ดูแลระบบ

---

Best Practices

• ใช้ Local Database เป็นแหล่งข้อมูลหลักสำหรับ Master Data
• ใช้ In-Memory Cache เพื่อเพิ่มความเร็วในการอ่านข้อมูลที่เรียกใช้บ่อย
• Synchronize ข้อมูลเป็นประจำตามรอบเวลา
• ไม่ Cache ข้อมูลที่ต้องการความถูกต้องแบบ Real-time
• บันทึกเวลาที่ Cache ล่าสุด เพื่อใช้ตรวจสอบอายุของข้อมูล

---

Related Sections

• 10.03 Master Data Synchronization Strategy
• 10.05 Retry & Recovery Strategy
• Chapter 5 Master Data APIs

---

Summary

การใช้ Cache อย่างเหมาะสมช่วยเพิ่มประสิทธิภาพของระบบ Integration ลดจำนวน API Calls และลดภาระของ SISAHYGO API โดยควรใช้ Cache สำหรับข้อมูลอ้างอิงที่เปลี่ยนแปลงไม่บ่อย เช่น ผู้รับสินค้า สินค้า และหน่วยนับ ขณะที่ข้อมูลที่ต้องการความเป็นปัจจุบัน เช่น สถานะการจัดส่งและรายการที่ถูกปฏิเสธ ควรเรียกจาก API โดยตรงเพื่อให้ได้ข้อมูลล่าสุด การผสมผสานระหว่าง Local Database, In-Memory Cache และการ Synchronize ตามรอบเวลาที่เหมาะสม จะช่วยให้ระบบมีความรวดเร็ว เสถียร และพร้อมรองรับการใช้งานในระดับ Production

---

Next Step

➡️ 10.05 Retry & Recovery Strategy