Signal แพลตฟอร์มเทเลเมทรีแบบเรียลไทม์

ปัญหา

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

แนวทาง

• SDK ขนาดเล็กที่กำหนดชนิดข้อมูล ตัวติดตาม TypeScript ตัวเดียวเก็บข้อมูลการกระทำของผู้ใช้แบบเดียวกันในทุกหน้าจอ ทั้งเว็บ มือถือ และ Mini Program อีเวนต์จึงมีความหมายเหมือนกันทุกที่
• ควบคุมจังหวะการส่งพร้อมวาล์วนิรภัย SDK เก็บอีเวนต์ไว้ในคิวและส่งทุก 3 วินาทีหรือเมื่อครบ 10 อีเวนต์ แล้วแต่อย่างใดถึงก่อน การส่งหนึ่งคำขอต่อหนึ่งคลิกจะทำให้เธรดเครือข่ายของเบราว์เซอร์ไม่พอใช้ ส่วนการเก็บไว้นานเกินไปก็เสี่ยงทำอีเวนต์หายเมื่อปิดแท็บ ตอนออกจากหน้าจะใช้ navigator.sendBeacon
• BFF ที่ตรวจสอบข้อมูล ชุดอีเวนต์จะเข้าสู่ Backend for Frontend ซึ่งตรวจสคีมาตามนิยามของ TypeScript ตรวจความสมเหตุสมผลของเวลา ตัดฟิลด์ที่ไม่คาดคิดและข้อมูลส่วนบุคคล (PII) ออก แล้วแนบข้อมูลเซสชันกับผลการตัดสินของแบ็กเอนด์ (ผ่าน ปฏิเสธ รอตรวจสอบ) การเทียบผลนี้กับสิ่งที่หน้าจอแสดงทำให้เห็นจุดที่สถานะระหว่าง UI กับแบ็กเอนด์ไม่ตรงกัน
• Kafka, Flink, ClickHouse, Grafana Kafka รับมือกับทราฟฟิกที่พุ่งสูงจากทั่วโลก Flink ประมวลผลอีเวนต์แบบเรียลไทม์ ClickHouse จัดเก็บข้อมูล (การจัดเก็บแบบคอลัมน์ตอบการรวมข้อมูลหลายพันล้านอีเวนต์ที่มีค่าหลากหลายสูงได้ในระดับมิลลิวินาที ขณะที่แบบแถวช้ามาก) และ Grafana แสดงฟันเนล
• จัดการความล้มเหลวอย่างเงียบ ๆ หากไปป์ไลน์ล่ม SDK จะเก็บอีเวนต์ได้สูงสุด 100 รายการใน localStorage และเซอร์กิตเบรกเกอร์แบบพาสซีฟจะหยุดการส่ง โดยไม่เรียกเซิร์ฟเวอร์เพื่อเช็กสถานะ แต่รอการตอบกลับที่สำเร็จครั้งถัดไป

ผลลัพธ์

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