ลูกค้าทักมาแล้วบอทตอบช้าไปสามวินาที เสียโอกาสไปเท่าไหร่: วางชั้น Cache ลดเวลาตอบสนองของ Webhook

ร้านขายชุดว่ายน้ำออนไลน์แห่งหนึ่งสังเกตว่าช่วงแคมเปญลดราคาที่มีคนทักเข้ามาพร้อมกันเยอะ ๆ บอทตอบกลับช้าลงอย่างเห็นได้ชัด จากที่เคยตอบภายในไม่ถึงวินาที กลายเป็นสามถึงสี่วินาที ซึ่งในโลกของแชท สามวินาทีคือความรู้สึกที่ 'ช้ามาก' พอสอบถามลูกค้าที่หายไปกลางทาง หลายคนบอกว่าคิดว่าระบบพังเลยปิดแชทไปเฉย ๆ

พอไล่ดูสาเหตุพบว่า ทุกครั้งที่มีข้อความเข้ามา ระบบจะไปสอบถามฐานข้อมูลหลักเพื่อเช็กว่า LINE UID นี้เคยถูกผูกกับ Click ID อันไหน เคยมีประวัติซื้อไหม อยู่ในกลุ่มลูกค้าประเภทไหน ซึ่งเป็นการสอบถามฐานข้อมูลเดิมซ้ำ ๆ ทุกครั้งทั้งที่ข้อมูลพวกนี้ไม่ได้เปลี่ยนบ่อยเลย พอมีคนทักพร้อมกันหลายร้อยคน ฐานข้อมูลหลักก็รับภาระหนักจนตอบช้าลง

ทางแก้ที่ตรงจุดที่สุดในกรณีแบบนี้คือการวางชั้น cache ซึ่งเป็นที่พักข้อมูลที่อ่านได้เร็วกว่าฐานข้อมูลหลักมาก สำหรับข้อมูลที่ถูกอ่านบ่อยแต่ไม่ได้เปลี่ยนบ่อย

อะไรควร cache อะไรไม่ควร

หลักการทำงานแบบคร่าว ๆ

แนวคิดพื้นฐานคือ เมื่อ webhook ต้องการข้อมูลบางอย่าง ให้เช็กที่ cache ก่อนเสมอ ถ้าเจอ (cache hit) ให้ใช้ค่านั้นตอบกลับได้ทันทีโดยไม่ต้องไปแตะฐานข้อมูลหลักเลย ถ้าไม่เจอ (cache miss) ค่อยไปสอบถามฐานข้อมูลหลัก แล้วเก็บผลลัพธ์ไว้ใน cache สำหรับการเรียกครั้งต่อไปด้วย

เครื่องมือที่นิยมใช้ทำ cache แบบนี้คือ Redis ซึ่งเก็บข้อมูลไว้ในหน่วยความจำ ทำให้อ่านได้เร็วกว่าฐานข้อมูลบนดิสก์มาก ระดับความเร็วต่างกันหลักสิบถึงร้อยเท่าในบางกรณี ซึ่งเป็นระดับที่รู้สึกได้จริงในแชทที่ต้องการตอบเร็ว เพราะความเร็วในการตอบสนองมีผลโดยตรงต่ออัตราการปิดการขาย

จุดที่พลาดบ่อยที่สุด: ไม่ตั้งเวลาหมดอายุให้เหมาะ

ปัญหาที่พบบ่อยที่สุดของทีมที่เพิ่งเริ่มทำ cache ไม่ใช่เรื่องความเร็ว แต่เป็นเรื่องข้อมูลเก่าค้างอยู่นานเกินไป เช่น cache ผลการซื้อของลูกค้าไว้แต่ไม่ตั้งเวลาหมดอายุ พอลูกค้าคนนั้นซื้อของใหม่ บอทก็ยังตอบด้วยข้อมูลเก่าที่ไม่ทันสมัยแล้ว ทำให้ลูกค้ารู้สึกว่าระบบไม่ฉลาดหรือดูไม่รู้จักเขาจริง

หลักที่ใช้ได้ผลคือแยกเวลาหมดอายุตามความถี่ในการเปลี่ยนแปลงของข้อมูลแต่ละประเภท ข้อมูลที่แทบไม่เปลี่ยนเลยอย่างการผูก UID อาจ cache ได้เป็นวันหรือสัปดาห์ ส่วนข้อมูลที่เปลี่ยนบ่อยอย่างสถานะออเดอร์ล่าสุดควรตั้งเวลาหมดอายุแค่ไม่กี่นาที หรือให้ระบบ invalidate cache ทันทีเมื่อมีการอัปเดตข้อมูลนั้นจริง

ธุรกิจแบบไหนที่ยังไม่ต้องรีบทำ

ถ้าปริมาณข้อความเข้าต่อวันยังไม่มาก (หลักสิบถึงหลักร้อยข้อความ) และไม่เคยมีปัญหาบอทตอบช้า อาจยังไม่จำเป็นต้องลงทุนวางระบบ cache ทันที เพราะเป็นความซับซ้อนเพิ่มที่ต้องดูแลรักษา ควรเริ่มทำเมื่อเริ่มสังเกตเห็นปัญหาจริง เช่นช่วงแคมเปญที่มีคนทักพร้อมกันเยอะ หรือเมื่อฐานข้อมูลลูกค้าโตจนการสอบถามแต่ละครั้งใช้เวลานานขึ้นเรื่อย ๆ ซึ่งมักเกิดควบคู่กับปัญหาคิวค้างที่อธิบายไว้ในสถาปัตยกรรม Queue กับ Retry และปัญหาwebhook ตามรอยข้อความไม่ทัน ที่พบบ่อยเมื่อฐานข้อมูลลูกค้าโตขึ้นเรื่อย ๆ

สรุป

ความเร็วในการตอบแชทไม่ใช่แค่เรื่องประสบการณ์ลูกค้า แต่เป็นเรื่องยอดขายโดยตรง เพราะทุกวินาทีที่รอ คือโอกาสที่ลูกค้าจะเปลี่ยนใจหรือไปเจอคู่แข่งที่ตอบเร็วกว่า

ชั้น cache ไม่ใช่คำตอบสำหรับทุกปัญหาความช้า แต่สำหรับข้อมูลที่อ่านบ่อยและเปลี่ยนไม่บ่อย มันคือการลงทุนที่คุ้มค่าและเห็นผลได้เร็วที่สุดอย่างหนึ่งในระบบ tracking

• webhook ที่สอบถามฐานข้อมูลหลักซ้ำ ๆ จะช้าลงเมื่อข้อมูลและปริมาณคนใช้งานโตขึ้น
• แยกประเภทข้อมูลว่าควร cache หรือไม่ตามความถี่ในการเปลี่ยนแปลง ไม่ใช่ cache ทุกอย่างเหมือนกัน
• จุดพลาดที่พบบ่อยที่สุดคือลืมตั้งเวลาหมดอายุให้เหมาะกับแต่ละประเภทข้อมูล

คำถามที่พบบ่อย