สร้างแชทบนเว็บแบบเรียลไทม์ จาก 0 ถึงโปรดักชัน

การสร้างระบบแชทบนเว็บให้ “ใช้งานได้จริง” ไม่ใช่แค่เชื่อม WebSocket แล้วส่งข้อความหากันได้เท่านั้น แต่ต้องคิดถึงความถูกต้องของข้อมูล ความต่อเนื่องเมื่อเครือข่ายมีปัญหา ความปลอดภัย และการรองรับการใช้งานพร้อมกันจำนวนมากด้วย

บทความนี้สรุปแนวทางออกแบบระบบแชทแบบเรียลไทม์ตั้งแต่เริ่มต้นไปจนถึงระดับโปรดักชัน โดยเน้นประเด็นที่มักกลายเป็นปัญหาเมื่อระบบเริ่มโต

1) เริ่มจากเป้าหมายและข้อกำหนดของระบบ

ก่อนลงมือพัฒนา ควรกำหนดให้ชัดว่าระบบแชทของเราต้องรองรับอะไรบ้าง เช่น

• แชทแบบตัวต่อตัว หรือแบบห้องสนทนา
• การเก็บประวัติข้อความย้อนหลัง
• สถานะอ่านแล้ว
• สถานะออนไลน์/ออฟไลน์
• การป้องกันสแปม
• การรองรับการเปิดใช้งานหลายแท็บหรือหลายอุปกรณ์

นอกจากนี้ควรกำหนดเป้าหมายเชิงคุณภาพของระบบ เช่น

• ข้อความควรถูกส่งถึงภายใน 1 วินาที
• รีเฟรชหน้าแล้วข้อความต้องไม่หาย
• ผู้ใช้ต้องสามารถโหลดประวัติย้อนหลังได้เสมอ

การตั้งข้อกำหนดเหล่านี้ตั้งแต่ต้นจะช่วยให้การออกแบบสถาปัตยกรรมไม่หลุดจากเป้าหมายการใช้งานจริง

2) ออกแบบฐานข้อมูลให้รองรับทั้งประวัติและสถานะ

ระบบแชทที่ดีต้องมีฐานข้อมูลเป็นศูนย์กลางความจริง โดยโครงสร้างพื้นฐานที่นิยมใช้ เช่น

• users: เก็บข้อมูลผู้ใช้
• conversations: เก็บข้อมูลห้องสนทนา
• conversation_members: เก็บสมาชิกในแต่ละห้อง พร้อมสถานะการอ่าน
• messages: เก็บข้อความทั้งหมด

ตัวอย่างฟิลด์สำคัญ ได้แก่

• users(id, name)
• conversations(id, type, created_at)
• conversation_members(conversation_id, user_id, last_read_message_id, joined_at)
• messages(id, conversation_id, sender_id, body, created_at)

จุดสำคัญคือการทำดัชนี เช่น messages(conversation_id, id) เพื่อให้การดึงข้อความย้อนหลังทำได้เร็วขึ้น

อีกเทคนิคที่มีประโยชน์มากคือการเก็บ last_read_message_id ต่อสมาชิกในห้อง แทนการไล่ตรวจจาก timestamp เพราะช่วยคำนวณจำนวนข้อความที่ยังไม่ได้อ่านได้มีประสิทธิภาพกว่า

3) แยกบทบาทของ HTTP และ WebSocket ให้ชัดเจน

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

แนวทางที่เหมาะสมคือ

HTTP ใช้สำหรับข้อมูลย้อนหลังและการทำงานที่ต้องเชื่อถือได้

ตัวอย่างเช่น

• GET /conversations/:id/messages?before=...&limit=50 สำหรับโหลดประวัติข้อความ
• POST /messages สำหรับส่งข้อความในกรณีสำรอง เช่น ตอน WebSocket หลุด หรือบางกรณีบนมือถือ

WebSocket ใช้สำหรับเหตุการณ์แบบเรียลไทม์

เช่น event ประเภท

• message:new
• read:upsert
• presence:update

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

4) ยืนยันตัวตนตั้งแต่ขั้นตอนเชื่อมต่อ

หากระบบแชทมีข้อมูลส่วนตัวหรือข้อมูลสำคัญ การยืนยันตัวตนต้องเกิดขึ้นตั้งแต่ handshake ของ WebSocket

แนวทางทั่วไปคือ

• ให้ client ส่ง token เช่น JWT ตอนเชื่อมต่อ
• server ตรวจสอบความถูกต้องของ token
• เมื่อผ่านแล้วจึงผูก userId เข้ากับ connection นั้น

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

5) ออกแบบ event ให้เป็นรูปแบบเดียวกัน

ระบบแชทจะดูแลง่ายขึ้นมาก หากทุก event ใช้โครงสร้างข้อมูลในรูปแบบเดียวกัน เช่น

• event
• requestId
• data
• ts

การมี requestId ช่วยให้จัดการกรณีส่งซ้ำหรือ retry ได้ดี โดยเฉพาะตอนเครือข่ายไม่เสถียร เช่น client ไม่แน่ใจว่าข้อความถูกส่งสำเร็จหรือยัง จึงส่งซ้ำอีกครั้ง

6) ส่งข้อความแบบไม่ซ้ำและไม่หาย

หนึ่งในปัญหาคลาสสิกของระบบแชทคือผู้ใช้กดส่งซ้ำ หรือแอป retry เองแล้วเกิดข้อความซ้ำในฐานข้อมูล

วิธีที่ใช้ได้จริงคือ

• ฝั่ง client สร้าง clientMessageId เช่น UUID
• ส่งข้อมูลผ่าน WebSocket พร้อม conversationId, body, clientMessageId
• ฝั่ง server ตรวจสอบความซ้ำจากคู่ค่า (senderId, clientMessageId)
• ถ้ายังไม่เคยมี จึงค่อยบันทึกลงฐานข้อมูล
• หลังจากนั้น server จึง broadcast message:new ไปยังสมาชิกในห้อง

ผลลัพธ์คือ ต่อให้ client ส่งคำขอเดิมซ้ำ ระบบก็ยังไม่สร้างข้อความซ้ำในฐานข้อมูล

7) โหลดประวัติย้อนหลังอย่างปลอดภัยด้วย cursor pagination

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

แนวทางที่เหมาะสมกว่าคือใช้ cursor-based pagination เช่น

• before=messageId
• limit=50

ข้อดีคือสามารถโหลดข้อความย้อนหลังแบบ infinite scroll ได้เสถียรกว่า และลดปัญหาลำดับข้อมูลเพี้ยนเมื่อมีข้อความใหม่แทรกเข้ามาตลอดเวลา

8) จัดการสถานะอ่านแล้วแบบประหยัดทรัพยากร

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

วิธีที่เรียบง่ายและมีประสิทธิภาพกว่าคือ

• เก็บ last_read_message_id ต่อสมาชิกใน conversation_members
• เมื่อผู้ใช้เปิดห้องและอ่านข้อความถึงจุดล่าสุด ให้ client ส่ง read:upsert
• server อัปเดตค่าเฉพาะเมื่อ messageId ใหม่มากกว่าค่าเดิม เพื่อให้สถานะเดินหน้าอย่างเดียว
• จากนั้น broadcast read:update ไปยังสมาชิกคนอื่นในห้อง

แนวทางนี้ทำให้ระบบติดตามได้ว่าผู้ใช้อ่านถึงข้อความใดแล้ว โดยไม่ต้องสร้าง record การอ่านแยกสำหรับทุกข้อความ

9) ทำสถานะออนไลน์/ออฟไลน์ให้แม่นยำ

การบอกว่าใครออนไลน์อยู่ไม่ใช่เรื่องง่าย โดยเฉพาะเมื่อผู้ใช้เปิดหลายแท็บหรือหลายอุปกรณ์พร้อมกัน

วิธีที่ใช้งานได้จริงคือเก็บจำนวน connection ต่อ userId

• เมื่อเชื่อมต่อ: count++
• เมื่อปิดการเชื่อมต่อ: count--
• หากเปลี่ยนจาก 0 -> 1 ให้ประกาศ presence:online
• หากเปลี่ยนจาก 1 -> 0 ให้ประกาศ presence:offline

ในทางปฏิบัติอาจหน่วงการประกาศออฟไลน์ประมาณ 5-15 วินาที เพื่อกันกรณีเน็ตกระตุกหรือ reconnect ทันที

10) ใช้ Heartbeat เพื่อตรวจจับการหลุดจริง

อีกปัญหาที่พบบ่อยคือ connection หลุดไปแล้ว แต่ระบบยังคิดว่าผู้ใช้ยังออนไลน์อยู่ หรือที่เรียกว่า ghost online

วิธีแก้คือใช้ heartbeat

• server ส่ง ping ทุก 20-30 วินาที
• client ตอบ pong กลับ
• ถ้าไม่ตอบภายในเวลาที่กำหนด ให้ตัด connection

กลไกนี้ช่วยให้สถานะออนไลน์แม่นขึ้น และช่วยทำความสะอาด connection ที่ค้างอยู่

11) ป้องกันสแปมและการใช้งานผิดรูปแบบ

ระบบแชทจำนวนมากมักพลาดเรื่อง abuse control ตั้งแต่ช่วงแรก ทำให้ต้องกลับมาแก้ภายหลังเมื่อเริ่มมีผู้ใช้จริง

สิ่งที่ควรมีตั้งแต่ต้น ได้แก่

• rate limit ต่อผู้ใช้ต่อห้อง เช่น 5 ข้อความต่อ 5 วินาที
• ตรวจข้อความว่าง
• จำกัดความยาวข้อความ
• จำกัดการส่งลิงก์ถี่เกินไป
• ทำ cooldown เมื่อผู้ใช้โดนจำกัด
• ส่ง error กลับอย่างสุภาพและเข้าใจง่าย

ที่สำคัญคือทุกอย่างต้องตรวจซ้ำที่ฝั่ง server ไม่ควรเชื่อข้อมูลจาก client เพียงอย่างเดียว

12) ออกแบบให้ทนทานเมื่อระบบขยายหลายเครื่อง

เมื่อระบบโตจนมี WebSocket server หลาย instance การ broadcast ภายในเครื่องเดียวจะไม่พออีกต่อไป เพราะผู้ใช้ในห้องเดียวกันอาจเชื่อมต่ออยู่คนละเครื่อง

แนวทางที่นิยมคือใช้ระบบกลางสำหรับกระจาย event เช่น

• Redis Pub/Sub
• NATS
• Kafka

บทบาทที่ชัดเจนควรเป็นดังนี้

• ฐานข้อมูลเป็น source of truth
• broker หรือ pub/sub เป็นช่องทางส่งต่อ event ระหว่างเครื่อง

ไม่ควรพึ่งพา room state ที่อยู่ใน memory ของเครื่องใดเครื่องหนึ่งเพียงอย่างเดียว เพราะเมื่อมีการย้ายเครื่อง รีสตาร์ต หรือ scale เพิ่ม ข้อมูลสถานะอาจหายหรือไม่สอดคล้องกันได้

13) ความปลอดภัยที่ขาดไม่ได้

ระบบแชทมักมีข้อมูลส่วนตัว จึงต้องระวังทั้งการเข้าถึงโดยไม่ได้รับสิทธิ์และการโจมตีผ่านข้อความ

สิ่งที่ควรทำ ได้แก่

• ตรวจสิทธิ์ทุกครั้งก่อนอ่านหรือส่งข้อความ ว่าผู้ใช้เป็นสมาชิกของ conversation นั้นจริง
• sanitize ข้อความก่อนแสดงผล เพื่อป้องกัน XSS
• จำกัดขนาด payload ของ WebSocket
• จำกัดจำนวน connection ต่อ IP

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

14) ทดสอบในสถานการณ์ที่ใกล้เคียงของจริง

ระบบแชทมักมีบั๊กที่ไม่โผล่ในการทดสอบทั่วไป แต่จะเจอเมื่อมีการใช้งานจริงพร้อมกันหลายรูปแบบ

กรณีที่ควรทดสอบอย่างน้อย ได้แก่

• เน็ตหลุดแล้ว reconnect: ข้อความต้อง sync กลับมาได้ครบ
• เปิดสองแท็บพร้อมกัน: presence และ read receipts ต้องไม่กระพริบผิด
• มีผู้ใช้สองคนส่งพร้อมกัน: ลำดับข้อความต้องถูกต้องตาม created_at หรือ id

การทดสอบลักษณะนี้จะช่วยลดปัญหาที่มักเกิดเฉพาะในระบบเรียลไทม์

15) แนวคิดสำคัญที่ควรจำ

หากต้องการมองภาพรวมของระบบแชทแบบง่ายที่สุด สามารถสรุปได้ดังนี้

• HTTP มีไว้สำหรับ “ดึงอดีต” และเป็นทางสำรองให้มั่นใจว่าข้อมูลไม่หาย
• WebSocket มีไว้สำหรับ “ส่งปัจจุบัน” ให้เกิดขึ้นแบบทันที
• ฐานข้อมูลคือแหล่งเก็บความจริง
• event คือกลไกกระจายข่าวสารให้ผู้ใช้เห็นการเปลี่ยนแปลงแบบเรียลไทม์

16) ฟีเจอร์ต่อยอดระดับโปรดักชัน

เมื่อระบบพื้นฐานมีความเสถียรแล้ว ค่อยต่อยอดด้วยความสามารถเพิ่มเติม เช่น

• ตัวบอกสถานะว่ากำลังพิมพ์
• การส่งไฟล์
• การแก้ไขหรือลบข้อความ
• end-to-end encryption
• full-text search

ฟีเจอร์เหล่านี้ช่วยยกระดับประสบการณ์ใช้งาน แต่ควรวางบนรากฐานที่แข็งแรงก่อนเสมอ

สรุป

การสร้างแชทบนเว็บแบบเรียลไทม์ที่ใช้งานได้จริง ต้องมองทั้งระบบ ไม่ใช่แค่การเชื่อม WebSocket ให้คุยกันได้เท่านั้น หัวใจสำคัญคือการแยกหน้าที่ระหว่าง HTTP และ WebSocket ให้ชัด ใช้ฐานข้อมูลเป็นแหล่งเก็บความจริง ออกแบบ event ให้สม่ำเสมอ ป้องกันข้อความซ้ำ รองรับการ reconnect และวางโครงสร้างให้ scale ข้ามหลายเครื่องได้

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