การอัปเดตกิจกรรมล่าสุดของผู้ใช้

ภาพรวม

ระบบจำเป็นต้องรู้ว่าผู้ใช้แต่ละคนยังเคลื่อนไหวอยู่หรือไม่ ทั้งเรื่องกิจกรรมล่าสุดเกิดขึ้นเมื่อใด เป็นกิจกรรมประเภทใด และเงียบหายไปนานเท่าไร ข้อมูลชุดนี้ถูกใช้ในสามที่ ได้แก่ การทำ segment เช่นเงื่อนไข "ผู้ที่ไม่มีกิจกรรมเกิน 30 วัน" การแสดงผลในหน้ารายชื่อผู้ใช้ของ CMS และการเป็นเงื่อนไขของ trigger rule บางประเภท

งานนี้เป็น consumer ขนาดเล็กที่ทำหน้าที่เพียงอัปเดตฟิลด์กลุ่ม last_activity_ บนแถว line_user โดยแยกออกมาเป็นคิวต่างหาก เพื่อไม่ให้การเขียนฐานข้อมูลไปถ่วง flow ที่ต้องตอบผู้ใช้แบบ realtime

Business Flow

1. รับ payload ชนิด LineUserActivityPayload ซึ่งประกอบด้วย lineUserId, lineOaId, organizationId พร้อมประเภทและสถานะของกิจกรรม
2. ProcessLineUserLastActivity ค้นหาแถว line_user ที่ตรงกับชุดคีย์ organizationId, lineOaId และ lineUserId
3. อัปเดตฟิลด์ 4 ตัว
   • last_activity_type คือประเภทของกิจกรรม เช่น message, follow หรือ click
   • last_activity_status คือสถานะ active หรือ inactive
   • last_activity_period คือช่วงเวลาที่คำนวณจากระยะห่างระหว่างกิจกรรม
   • last_activity_date คือเวลาปัจจุบันที่บันทึก
4. ระบบมี Redis cache ของแถว line_user ที่ key LINE_USER:<lineUserId> ซึ่งถูกอ่านโดย flow อื่นในระบบด้วย
5. service จัดการข้อผิดพลาดภายในตัวเอง คือบันทึก log แล้วจบงาน ทำให้ handler คืนค่า nil เสมอและ ack ทุกข้อความ ซึ่งตรงกับพฤติกรรมของระบบเดิม เหตุผลคืองานอัปเดต metadata ไม่ควรทำให้ข้อความค้างอยู่ในคิว

ไฟล์และฟังก์ชันหลัก

• internal/lineuser/service.go
  • Service.ProcessLineUserLastActivity(ctx, payload) — ลำดับการทำงานหลัก
  • findByLineUserId() — อ่านจาก Redis cache ที่ key LINE_USER:<id> ก่อน แล้วจึง fallback ไปอ่านฐานข้อมูล โดยมีข้อสังเกตว่าฟังก์ชันนี้ไม่เขียน cache กลับตอน miss ซึ่งตรงกับพฤติกรรมของ source เดิม
  • ค่าคงที่ moduleName มีค่าเป็น LINE_USER ใช้เป็น prefix ของ Redis key
• internal/lineuser/consumer.go — Consumer.HandleTrackingLog ผูกกับคิว line_user_last_activity
• internal/lineuser/types.go — นิยามชนิด LineUserActivityPayload
• คิวที่เกี่ยวข้อง: line_user_last_activity (runtime profile main)

จุดเชื่อมต่อกับ Service อื่น

• ต้นทางของงาน — line-management-webhook-go และเส้นทาง tracking หรือ redirect ที่ต้องการบันทึกกิจกรรมโดยไม่ block การตอบกลับ
• ฐานข้อมูล — ตาราง line_user โดยอัปเดตฟิลด์ last_activity_type, last_activity_status, last_activity_period และ last_activity_date
• Redis — key LINE_USER:<lineUserId>
• ไม่เรียก LINE API
• ผู้ใช้ข้อมูลปลายทาง — audience filter ฝั่ง cms-api, trigger rule ที่ใช้เงื่อนไขระดับ attribute และรายงานผู้ใช้ใน cms-web