System Design

01เริ่มจาก Requirement และ Invariant

ก่อนวาด architecture ให้ถามว่าคำว่า “ตั๋วไม่ซ้ำ” หมายถึงอะไร สำหรับระบบเลือกที่นั่ง invariant หลักคือ หนึ่ง `(event_id, seat_id)` มี active owner ได้ไม่เกินหนึ่งคน และ invariant นี้ต้องถูกบังคับที่ authoritative data store ไม่ใช่แค่ตรวจจาก cache หรือ UI

02State Machine และ Data Model

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

เก็บ current ownership ไว้ใน `seat_inventory` ส่วนประวัติการพยายามจองและ state transition อยู่ใน reservations/audit log จะทำให้ constraint หลักเรียบและยังตรวจสอบย้อนหลังได้

03มีวิธีป้องกันการจองซ้ำแบบใดบ้าง?

ตัวเลือกที่แนะนำเป็นแกนหลัก

เริ่มด้วย atomic conditional update หรือ unique constraint ใน PostgreSQL เพราะ correctness อยู่ใกล้ข้อมูลที่สุด และเพิ่ม Redis/queue เมื่อมีผลวัดว่า DB เป็น bottleneck ไม่ควรเริ่มจาก distributed lock หาก transaction เดียวแก้ปัญหาได้

UPDATE seat_inventory
SET status = 'HELD',
    hold_id = $3,
    hold_expires_at = now() + interval '5 minutes',
    version = version + 1
WHERE event_id = $1
  AND seat_id = $2
  AND (
    status = 'AVAILABLE'
    OR (status = 'HELD' AND hold_expires_at < now())
  )
RETURNING hold_id, hold_expires_at;

-- ได้ 1 row = จองชั่วคราวสำเร็จ
-- ได้ 0 row = มีคนถือหรือซื้อที่นั่งไปแล้ว

CREATE UNIQUE INDEX one_active_reservation_per_seat
ON reservations (event_id, seat_id)
WHERE status IN ('HELD', 'PAYMENT_PENDING', 'CONFIRMED');

-- เก็บประวัติรายการที่หมดอายุหรือยกเลิกได้
-- แต่มี active reservation ต่อที่นั่งได้เพียงหนึ่งรายการ

04Architecture ที่เริ่มได้และ Scale ต่อได้

Read path สามารถใช้ Redis cache สำหรับ seat map ได้ แต่ผลจาก cache เป็นเพียงภาพประมาณการ เมื่อผู้ใช้กด hold ต้องผ่าน atomic write ที่ database ทุกครั้ง หลัง state เปลี่ยนให้ publish event ผ่าน transactional outbox เพื่อ update cache, notification และ analytics โดยไม่ทำ dual write ตรง ๆ

1. 1
   POST /holds

   รับ event, seat และ Idempotency-Key; atomic update เป็น HELD พร้อม expiry

2. 2
   เริ่ม Payment

   เปลี่ยน HELD → PAYMENT_PENDING ก่อนเรียก provider และผูก provider reference

3. 3
   รับ Webhook

   ตรวจ signature และ deduplicate ด้วย provider event ID

4. 4
   Confirm

   เปลี่ยน reservation เป็น CONFIRMED และออก ticket ใน transaction เดียว

05Payment และ Partial Failure

เราไม่สามารถครอบ transaction ของ database และ payment provider ด้วย ACID transaction เดียวได้ จึงใช้ Saga และ reconciliation ถ้าจ่ายสำเร็จแต่ confirm ไม่สำเร็จ ให้ retry จาก durable payment event หากจองที่นั่งไม่ได้จริงต้องมี compensation เช่น refund และส่งเข้าคิวตรวจสอบ

• ก่อน redirect ไปจ่ายเงิน เปลี่ยน state เป็น PAYMENT_PENDING แบบ atomic เพื่อหยุด expiry worker
• ใช้ provider reference และ webhook event ID เป็น unique key ป้องกัน callback ซ้ำ
• อย่าเชื่อ redirect จาก browser เป็นหลักฐานการชำระเงิน ให้ยืนยันกับ signed webhook หรือ query provider
• มี reconciliation job เทียบ payment ที่สำเร็จกับ reservation ที่ยังไม่ confirmed

06Failure Cases ที่ควรตอบให้ครบ

สำหรับ flash sale เพิ่ม virtual waiting room, per-user rate limit, bot protection และ partition ข้อมูลตาม event แต่ระวังว่าที่นั่งยอดนิยมยังเป็น hot key/row ต่อให้ shard ระบบแล้ว

07แนวตอบภายใน 3–5 นาที