EventEmitter ต่างจากคิวงานใน Node.js อย่างไร?

Question

IT Interview Practice · Accepted Answer

เลือกระหว่าง EventEmitter กับ job queue โดยถามว่า **งานต้องรันที่ใด และจะเกิดอะไรขึ้นถ้า process หยุด**

EventEmitter แจ้ง listener ภายใน Node.js process เดียว Durable queue เก็บงานให้ worker ประมวลผลภายหลัง ทั้งคู่แยกความรับผิดชอบได้ แต่พฤติกรรมเมื่อล้มเหลวต่างกัน

## 1. ติดตามการแจ้งเตือนภายใน process

สมมติ component เริ่มต้นทำงานเสร็จและต้องการให้ component อื่นใน process เดียวตอบสนอง EventEmitter เหมาะกับกรณีนี้: ลงทะเบียน listener แล้ว emit event

```text
[One process]
emit("ready") -> Listener A
              -> Listener B
```

Node.js เรียก listener ที่ลงทะเบียนไว้แบบ synchronous ตามลำดับการลงทะเบียน ตัว event ไม่ถูกเก็บไว้ให้ listener ที่มาลงทะเบียนทีหลัง และงานที่ยังไม่เสร็จไม่คงอยู่หลัง process crash ดู [Node.js Events](https://nodejs.org/api/events.html)

เหมาะเมื่อการแจ้งเตือนอยู่ภายในและยอมให้หายหรือสร้างใหม่ได้ แต่ไม่เพียงพอเมื่อธุรกิจคาดหวังให้งานอยู่ต่อแม้ผู้ส่งหยุดไปแล้ว

## 2. เข้าใจว่า async listener เปลี่ยนอะไร

Async listener อาจเริ่มงาน asynchronous แต่ emit ไม่รอ promise ที่ส่งกลับ ลำดับการเรียกจึงไม่จำเป็นต้องเป็นลำดับที่งานเสร็จ

โค้ด synchronous ที่ใช้ CPU หนักภายใน listener ยังทำให้ process ล่าช้า ต้องจัดการ error ที่ throw และ promise ที่ reject อย่างตั้งใจ captureRejections ส่ง rejection ไปยังตัวจัดการ error ได้ แต่ไม่เก็บงานอย่างถาวรหรือ retry ให้

การเพิ่ม async เปลี่ยนวิธีทำงานของ listener ไม่ได้เปลี่ยน event ในหน่วยความจำให้เป็น durable queue

## 3. ติดตามงานใน queue

คราวนี้สมมติว่าหลังบันทึกคำสั่งซื้อต้องออกใบแจ้งหนี้ให้ได้ในที่สุด Queue มีที่เก็บคำสั่งไว้ระหว่างที่ worker ไม่พร้อมหรือกำลังยุ่ง

```text
[Producer] -> [Durable queue] -> [Available worker]
                    |                   |
              [Pending work]      [Result / retry]
```

Producer ส่ง job ส่วน worker ประมวลผลแต่ละครั้งและบันทึกผล สามารถ deploy และขยาย worker แยกจาก API ได้ แต่ความคงทนยังขึ้นกับที่จัดเก็บและ configuration ของ queue

Queue ทั่วไปที่ worker แข่งกันรับงาน จะมี worker เดียวทำแต่ละ attempt ซึ่งต่างจาก broadcast event ให้ทุก listener ของ EventEmitter หาก subscriber อิสระหลายตัวต้องได้รับ event เดียวกันทุกตัว ให้เลือกหรือกำหนดรูปแบบส่งที่รองรับความต้องการนั้น

## 4. ตรวจช่องว่างระหว่างการบันทึกกับการส่งเข้า queue

สำหรับ EventEmitter หาก crash หลังบันทึกคำสั่งซื้อแต่ก่อน emit คำสั่งออกใบแจ้งหนี้อาจหาย Durable queue ป้องกัน job หลังรับแล้ว แต่ไม่ได้ป้องกันช่องว่างก่อนหน้านั้นระหว่าง commit ฐานข้อมูลกับส่งงานโดยอัตโนมัติ

Outbox ปิดช่องว่างโดยบันทึกคำสั่งซื้อและคำสั่งทำงานใน transaction ฐานข้อมูลเดียวกัน Publisher อ่าน outbox แล้วส่ง job ภายหลัง

การส่งอาจซ้ำหาก publisher ไม่ได้รับการยืนยัน กำหนด business key คงที่ให้การออกใบแจ้งหนี้ และใช้ unique constraint หรือวิธี idempotent อื่น การลองซ้ำต้องไม่สร้างใบแจ้งหนี้ใบที่สอง ดู [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs)

## 5. เปรียบเทียบตามความต้องการจริง

| ข้อกำหนด | EventEmitter | Durable job queue |
| --- | --- | --- |
| แจ้ง component ใน process เดียว | ตรงไปตรงมาและเบา | มักเพิ่มโครงสร้างพื้นฐานเกินจำเป็น |
| เก็บงานค้างหลังผู้ส่งหยุด | ไม่มีระเบียนคงทนในตัว | ทำได้ด้วยการจัดเก็บและการกู้คืนที่เหมาะสม |
| Retry และตรวจงานค้าง | แอปพลิเคชันต้องสร้างเอง | เป็นความสามารถทั่วไปของ queue ที่ต้องกำหนดค่า |
| ทำงานบนเครื่องอื่น | ไม่ใช่หน้าที่ของมัน | Worker ทำงานแยกกันได้ |

สำหรับตัวอย่างการเริ่มต้น component ผมจะใช้ EventEmitter สำหรับการออกใบแจ้งหนี้ที่ต้องกู้คืนจากความล้มเหลว ผมจะใช้ durable queue และจัดการการส่งต่อจากฐานข้อมูลกับ attempt ที่ซ้ำ

ทดสอบโดยหยุด process ตามจุดสำคัญ: ก่อนส่ง หลังรับงาน และหลังเกิดผลทางธุรกิจ ผลที่ได้ต้องตรงกับการรับประกันที่ผู้ใช้คาดหวัง

**จำไว้:** การแจ้งภายใน → EventEmitter; งานเบื้องหลังที่กู้คืนได้ → durable queue สำหรับผลสำคัญ ต้องออกแบบการส่งต่อและ idempotency ด้วย

ข้อกำหนด	EventEmitter	Durable job queue
แจ้ง component ใน process เดียว	ตรงไปตรงมาและเบา	มักเพิ่มโครงสร้างพื้นฐานเกินจำเป็น
เก็บงานค้างหลังผู้ส่งหยุด	ไม่มีระเบียนคงทนในตัว	ทำได้ด้วยการจัดเก็บและการกู้คืนที่เหมาะสม
Retry และตรวจงานค้าง	แอปพลิเคชันต้องสร้างเอง	เป็นความสามารถทั่วไปของ queue ที่ต้องกำหนดค่า
ทำงานบนเครื่องอื่น	ไม่ใช่หน้าที่ของมัน	Worker ทำงานแยกกันได้

1. ติดตามการแจ้งเตือนภายใน process

2. เข้าใจว่า async listener เปลี่ยนอะไร

3. ติดตามงานใน queue

4. ตรวจช่องว่างระหว่างการบันทึกกับการส่งเข้า queue

5. เปรียบเทียบตามความต้องการจริง

คำถามที่เกี่ยวข้อง