Signal، منصة قياس عن بُعد في الوقت الفعلي

المشكلة

مرّ ملايين الأشخاص في أكثر من 100 دولة بعملية التحقق من الهوية، وتوقف بعضهم في منتصف الطريق دون أن يلاحظ أحد. عندما يتعطل تكامل مع أحد المزوّدين، لم يكن أحد يرى ذلك: كنا نقرأ سجلات الخوادم المتفرقة يدويًا، ويستغرق التشخيص الواحد من يوم إلى ثلاثة أيام. وكل يوم من هذه الأيام يعني مستخدمين حقيقيين لم يتمكنوا من إكمال التسجيل.

النهج

• حزمة SDK صغيرة بأنواع صارمة. أداة تتبع واحدة بلغة TypeScript تجمع بيانات تفاعل المستخدم نفسها في كل شاشة، على الويب والجوال وMini Program، فيكون للحدث المعنى نفسه في كل مكان.
• تنظيم الإرسال مع صمّام أمان. تضع الحزمة الأحداث في طابور وترسلها كل 3 ثوانٍ أو عند تجمّع 10 أحداث، أيهما أسبق. إرسال طلب لكل نقرة يستنزف خيوط الشبكة في المتصفح، والاحتفاظ بالأحداث مدة أطول يعرّضها للضياع عند إغلاق التبويب. وعند مغادرة الصفحة تستخدم navigator.sendBeacon.
• طبقة BFF تتحقق من البيانات. تصل الدفعات إلى Backend for Frontend الذي يتحقق من المخطط وفق تعريفات TypeScript، ويفحص منطقية الطوابع الزمنية، ويزيل الحقول غير المتوقعة والبيانات الشخصية (PII)، ثم يضيف بيانات الجلسة وحكم الخادم (مقبول، مرفوض، بانتظار المراجعة). ومقارنة هذا الحكم بما عرضته الواجهة كشفت حالات عدم تطابق بين الواجهة والخادم.
• Kafka وFlink وClickHouse وGrafana. يستوعب Kafka ذروات حركة المرور العالمية، ويعالج Flink الأحداث في الوقت الفعلي، ويخزّنها ClickHouse (التخزين العمودي يجيب عن التجميعات على مليارات الأحداث عالية التنوع خلال أجزاء من الثانية، بينما يتباطأ التخزين القائم على الصفوف كثيرًا)، ويعرض Grafana مسارات التحويل.
• التعامل الهادئ مع الأعطال. إذا توقف خط المعالجة، تحتفظ الحزمة بما يصل إلى 100 حدث في localStorage، ويوقف قاطع دائرة سلبي الإرسال. لا ترسل طلبًا إلى الخادم للتحقق من حالته، بل تنتظر الاستجابة الناجحة التالية.

النتيجة

انخفض زمن اكتشاف العطل من 24–72 ساعة إلى أقل من 5 دقائق. وفي مسار يعني فيه تعطل خطوة واحدة لدى مزوّد آلاف التسجيلات الفاشلة، هذا هو الفرق بين ملاحظة في تقرير ما بعد الحادثة وإصلاح في صباح اليوم نفسه.