Queue และ Priority: ใครควรได้งานก่อน
เข้าใจ “Queue และ Priority: ใครควรได้งานก่อน” ผ่านงานธุรกิจไทยและผลกระทบต่อความเร็ว ความถูกต้อง และความเป็นธรรม
เป้าหมาย: เลือกโครงสร้างและตั้งคำถามเรื่อง scale ได้โดยไม่ต้องเป็นโปรแกรมเมอร์ · ใช้เวลาประมาณ 15 นาที
Question → Structure → Operation → Trade-off
เลือกโครงสร้างจากคำถามและการเปลี่ยนแปลง ไม่ใช่จากชื่อที่คุ้น
Question
ต้องค้น เรียง เชื่อม คิว หรือเดินตามลำดับอะไร
Structure
เลือก representation และ identifier
Operation
ระบุ read/write/update/delete และความถี่
Trade-off
วัดเวลา พื้นที่ freshness fairness และ failure
แนวคิดที่ใช้คุยกับทีม
queue
อธิบาย queue ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
วาดตัวอย่างข้อมูลเล็กก่อนเลือก implementation
priority
อธิบาย priority ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน
FIFO
อธิบาย FIFO ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน
starvation
อธิบาย starvation ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน
แบบจำลองที่ทำให้ระบบผิด
ไม่มี stable key
ข้อมูลซ้ำหรืออัปเดตผิดคน
กำหนด identity/matching rule
priority ไม่มีเหตุผล
ไม่ยุติธรรมและตรวจไม่ได้
ประกาศ criteria/tie-break
ทดสอบแต่ข้อมูลน้อย
latency/cost ระเบิดเมื่อ scale
load test และ complexity review
ออกแบบโครงสร้างจากงาน
ทีมบริการลูกค้ามี FAQ complaint refund และเหตุความปลอดภัยเข้าพร้อมกัน
กำหนด entity/key, structure, operations, edge cases, scale และ metric
ดูคำตอบตัวอย่าง
ระบุ source of truth และ stable key เลือก list/map/queue/tree/graph/index ตามคำถาม เขียน operations และ tie-break ตรวจ duplicate/cycle/stale index วัด latency, memory, fairness และ cost ที่ปริมาณปัจจุบันกับอนาคต พร้อม fallback เมื่อข้อมูลผิด
- entity/key
- structure
- operations
- edge cases
- scale
- metric/fallback
บันทึกช่วยจำ
- โครงสร้างเดียวอาจมี implementation หลายแบบ ให้ทีมเทคนิควัดกับ workload จริง
- การ ranking คนหรือสิทธิ์ต้องตรวจ bias และผลกระทบ
สรุปบทเรียนนี้
- เริ่มจากคำถาม
- มี key และ operation ชัด
- วัด trade-off เมื่อ scale