Lock Seat — การเลือกที่นั่งและถือสิทธิ์ระหว่างชำระเงิน

Lock Seat ระหว่างจ่ายเงิน: คู่มือจองที่นั่งให้มั่นใจไม่ซ้ำ

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

Lock Seat — การเลือกที่นั่งและถือสิทธิ์ระหว่างชำระเงิน
ภาพประกอบแนวคิด: การเลือกที่นั่งและถือสิทธิ์ระหว่างชำระเงิน

Lock Seat คืออะไร

ในบริบทการจอง Lock Seat คือการกันที่นั่งให้ลูกค้าตามช่วงเวลา เช่น Hold 10 นาที โดยสถานะต้องผูกกับรอบ ที่นั่ง เจ้าของ Hold และ Hold ID ที่ไม่ซ้ำ

Database Row Lock เป็นกลไกสั้น ๆ ที่ใช้ตอนเปลี่ยนสถานะ ส่วน Business Hold อยู่ได้หลายนาทีหลัง Commit ต้องแยกสองเรื่องนี้เพื่อลดการรอและการกิน Connection

กลไกถือสิทธิ์และหมดอายุ

เมื่อขอที่นั่ง ให้เปลี่ยนจาก Available หรือ Held ที่หมดอายุเป็น Hold ใหม่แบบมีเงื่อนไข แล้วคืนเวลาหมดอายุจาก Server การยืนยันต้องตรวจ Hold ID, Owner และสถานะปัจจุบันก่อนเปลี่ยนเป็น Confirmed

Redis Distributed Locks อธิบายความสำคัญของค่าเจ้าของ Lock และความเสี่ยงของการหมดอายุหรือ Failover หากใช้ Redis เป็นส่วนเสริม ต้องยังรักษาความถูกต้องของการจองในแหล่งข้อมูลหลัก

Architecture ของระบบถือที่นั่ง

Lock Seat — แผนภาพองค์ประกอบระบบและจุดควบคุมสำคัญ
แผนภาพองค์ประกอบและจุดควบคุมสำคัญ

Web/App → Seat Availability → Reservation Service → Seat/Reservation Database → Payment → Confirmation ใช้ WebSocket หรือ Polling เพื่อแสดงสถานะ แต่ไม่ใช้สถานะหน้าจอเป็นหลักฐานการจอง

กำหนด Unique Key ของที่นั่งต่อรอบ และจัดเก็บประวัติ Reservation แยกเมื่อจำเป็น เพื่อให้ติดตาม Hold ที่หมดอายุหรือชำระล่าช้าได้

Workflow ระหว่างเลือกที่นั่งกับจ่ายเงิน

Lock Seat — ลำดับขั้นตอนการทำงานและจุดตรวจสอบ
แผนภาพลำดับการทำงาน
  1. Client ส่งรอบและที่นั่งที่ต้องการ
  2. Server ตรวจและถือสิทธิ์ใน Transaction สั้น
  3. สร้าง Payment ผูกกับ Reservation เดิม
  4. Client แสดง Countdown จากเวลา Server
  5. ยืนยันจากผลชำระที่ตรวจได้และสถานะ Hold ที่ยังใช้ได้
  6. เมื่อหมดอายุ ปล่อยเฉพาะ Hold ID ที่ตรงกัน
  7. จัดการผลชำระล่าช้าตามนโยบายโดยไม่แย่งที่นั่งใหม่

ประโยชน์ทางธุรกิจและเทคนิค

ลูกค้ามีเวลาชำระโดยรู้ว่าถือสิทธิ์ถึงเมื่อไร ทีมงานตรวจปัญหาจาก Reservation ID ได้ ทีมเทคนิคไม่ต้องค้าง Transaction ระหว่างรอระบบภายนอก

Hold ยาวช่วยลูกค้าบางประเภทแต่ลดโควตาที่ขายได้ Hold สั้นเพิ่มการหมุนเวียนแต่เสี่ยงหมดอายุระหว่างจ่าย ควรเลือกตามช่องทางชำระและพฤติกรรมจริง พร้อมสื่อสารเงื่อนไขชัดเจน

กรณีใช้งาน: Hold A หมดอายุแล้ว Hold B เข้ามา

ตัวอย่างสมมติ: ลูกค้า A ถือที่นั่งแล้วหมดอายุ ลูกค้า B ถือที่นั่งเดียวกัน จากนั้นงาน Cleanup ของ A มาถึง ต้องอัปเดตได้เฉพาะเมื่อ Hold ID ยังเป็น A เท่านั้น

ถ้า Payment ของ A สำเร็จภายหลัง ห้ามเปลี่ยน Seat ของ B เป็นของ A ต้องเข้ารายการตรวจและคืนเงินหรือจัดทางเลือกตามนโยบายที่แจ้งไว้

Security และการกักที่นั่ง

ตรวจเจ้าของ Hold และใช้ Token ที่เดาได้ยาก จำกัดจำนวน Hold ต่อผู้ใช้และอัตราคำขอ ไม่เชื่อว่า Hold เป็นของผู้ใช้เพียงเพราะ Client ส่ง ID มา

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

Scalability และ Integration

การถือหลายที่นั่งในคำขอเดียวต้องกำหนด All-or-nothing และใช้ลำดับล็อกคงที่เพื่อลด Deadlock แสดง Availability ผ่าน Cache ได้ แต่ตัดสิน Hold จากข้อมูลที่ควบคุมธุรกรรม

ช่องทางชำระที่ใช้เวลานานอาจต้องมีเงื่อนไขต่างจากบัตร เช่น ไม่เปิดให้ถือที่นั่งแบบเดียวกันทั้งหมด กำหนดวิธี Reconciling Payment กับ Reservation ให้เป็นส่วนหนึ่งของระบบ

ปัญหาที่พบบ่อยและ Best Practices

ปัญหาคือใช้ Clock ลูกค้า ปล่อยตาม Seat ID โดยไม่ตรวจ Hold ID และ Cleanup กับ Payment แข่งขันโดยไม่มีเงื่อนไข ควรใช้เวลา Server และ State Transition ที่ตรวจสถานะเดิมทุกครั้ง

เมื่ออ่านที่นั่งที่ Hold หมดอายุ อย่าอาศัย Cron เท่านั้น สามารถตรวจ Expiry ในธุรกรรมขอถือใหม่ได้ โดยต้องยังจัดการประวัติและการปล่อยอย่างไม่ซ้ำ

แนวทางระยะถัดไป

เพิ่ม Waiting Room หรือจำกัดคำขอเข้าระบบเมื่อตลาดเปิดขายพร้อมกันได้ แต่ต้องคงกฎเจ้าของ Hold และการตัดสินที่แหล่งข้อมูลหลัก การปรับเวลาถือสิทธิ์ควรมีข้อมูลสนับสนุนและไม่เปลี่ยน Hold ที่กำลังใช้โดยไม่แจ้ง

สรุป Lock Seat ที่ถูกต้อง

ออกแบบ Lock Seat เป็น Business Hold ที่มีอายุและเจ้าของ ใช้ Database Transaction สั้นในการเปลี่ยนสถานะ และให้ทุกการยืนยันหรือปล่อยตรวจ Hold ID ปัจจุบันก่อนเสมอ

จุดตรวจสำคัญของ Lock Seat

  • Unique Seat ต่อ Session
  • Hold มี Owner, ID และ Expiry จาก Server
  • ไม่มี Transaction ค้างระหว่างรอจ่าย
  • Cleanup ตรวจ Hold ID ก่อนปล่อย
  • Late Payment ไม่แย่งที่นั่งใหม่

เตรียมข้อมูลเพื่อประเมินระบบกับ Zairosoft

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

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

ต้องล็อกฐานข้อมูลตลอดเวลาชำระเงินไหม?

ไม่ควร ใช้ Transaction สั้นเพื่อบันทึก Hold แล้ว Commit เก็บวันหมดอายุและเจ้าของในข้อมูลธุรกิจแทน

Hold ควรนานกี่นาที?

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

ผู้ใช้ปิดหน้าเว็บต้องปล่อยทันทีไหม?

ไม่ควรพึ่งเหตุปิด Browser เป็นกลไกหลัก ให้ Server ใช้ Expiry และเงื่อนไขยกเลิกที่ตรวจเจ้าของได้

ถือหลายที่นั่งแล้วได้ไม่ครบควรทำอย่างไร?

กำหนดนโยบายให้ชัด โดยทั่วไปคำขอชุดเดียวอาจใช้ All-or-nothing เพื่อไม่ให้ลูกค้าได้ชุดที่นั่งไม่ตรงความต้องการ

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