สร้างระบบแจ้งเตือนเรียลไทม์ตลาดซื้อขายสินค้ามือสอง

โปรเจกต์ตลาดซื้อขายสินค้ามือสองส่วนใหญ่มักทำระบบแจ้งเตือนผิดวิธีตั้งแต่ต้น โดยมักจะสร้างหน้าประกาศสินค้า ตัวกรองการค้นหา ระบบชำระเงิน แล้วค่อยมาใส่ระบบแจ้งเตือนทีหลังด้วยการเรียก Firebase สามจุดพร้อมทิ้งคอมเมนต์ไว้ในโค้ดว่าจะปรับปรุงทีหลัง ปัญหาคือการส่งการแจ้งเตือนไม่ได้เป็นเพียงแค่ฟีเจอร์ แต่เป็นโครงสร้างพื้นฐาน และการตัดสินใจเกี่ยวกับโครงสร้างพื้นฐานที่ทำช้าเกินไปมักเป็นสิ่งที่ต้องจ่ายต้นทุนแพงที่สุดในระยะยาว ผู้ซื้อที่พลาดการแจ้งเตือนราคาลดลงก็อาจจะเดินจากไป ส่วนผู้ขายที่พลาดข้อความตอบกลับก็อาจย้ายไปใช้บริการคู่แข่ง การประกาศสินค้าจึงปิดตัวลงโดยไม่มีการทำธุรกรรมเกิดขึ้น และแพลตฟอร์มก็ไม่ได้เรียนรู้อะไรเลยจากเหตุการณ์นั้น

บทความนี้มีขึ้นสำหรับนักพัฒนาที่กำลังสร้างแพลตฟอร์มตลาดซื้อขายสินค้ามือสองและต้องการวางแผนระบบแจ้งเตือนล่วงหน้าก่อนที่มันจะกลายเป็นปัญหา สถาปัตยกรรมที่ใช้นั้นไม่ได้มีความซับซ้อน แต่การตัดสินใจในแต่ละขั้นตอนมีความสำคัญอย่างยิ่ง และมีลำดับขั้นตอนเฉพาะที่จะช่วยหลีกเลี่ยงข้อผิดพลาดทั่วไปที่พบบ่อยที่สุด ตามงานวิจัยที่ตีพิมพ์ในวารสาร IJARCST ระบุว่าสถาปัตยกรรมแบบขับเคลื่อนด้วยเหตุการณ์ หรือ Event-driven architectures ซึ่งเป็นระบบที่บริการต่างๆ ส่งเหตุการณ์ไปยังบัสส่วนกลางแทนที่จะเรียกปลายทางในการส่งข้อมูลโดยตรง ถือเป็นรากฐานสำคัญที่ช่วยให้ระบบแจ้งเตือนสามารถขยายขนาดได้โดยไม่เกิดความกระจัดกระจาย

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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

เมื่อพูดถึงการเลือกเทคโนโลยีการขนส่งข้อมูล ทีมพัฒนาส่วนใหญ่มักจะเลือกซับซ้อนเกินความจำเป็นหรือเรียบง่ายเกินไป ทางเลือกประเภทต่างๆ มีข้อดีข้อเสียแตกต่างกัน เริ่มตั้งแต่ Long Polling หรือ Short Polling ที่ไคลเอนต์จะคอยส่งคำถามไปยังเซิร์ฟเวอร์เป็นระยะ การเชื่อมต่อแบบ SSE (Server-Sent Events) ที่เปิดการเชื่อมต่อ HTTP ระยะยาวเพื่อให้เซิร์ฟเวอร์ส่งข้อมูลหาไคลเอนต์ได้ทางเดียว ซึ่งเหมาะสำหรับฟีดการแจ้งเตือน ตามคู่มือสำหรับนักพัฒนาปี 2026 ระบุว่า SSE คือค่าเริ่มต้นที่ถูกต้องสำหรับการแจ้งเตือนที่ไคลเอนต์มีหน้าที่รับฟังฝ่ายเดียว และสุดท้ายคือ WebSocket ที่เปิดการเชื่อมต่อแบบสองทิศทางพร้อมกัน เหมาะสำหรับระบบแชทสดระหว่างผู้ซื้อและผู้ขายที่ต้องพิมพ์และอ่านข้อความพร้อมกันแบบเรียลไทม์

ที่มา: Dev.to