Signal, une plateforme de télémétrie en temps réel

Le problème

Des millions de personnes dans plus de 100 pays passaient par la vérification d’identité, et certaines abandonnaient sans que personne ne le remarque. Quand une intégration fournisseur cassait, personne ne le voyait : nous lisions à la main des logs serveur éparpillés, et un diagnostic prenait un à trois jours. Chacun de ces jours, c’étaient de vrais utilisateurs qui ne pouvaient pas terminer leur inscription.

L’approche

• Un petit SDK typé. Un seul traceur TypeScript collectait les mêmes données d’actions utilisateur sur chaque écran, sur le web, le mobile et le Mini Program, pour que les événements aient partout le même sens.
• Une limitation avec soupape de sécurité. Le SDK met les événements en file d’attente et les envoie toutes les 3 secondes ou à 10 événements, selon ce qui arrive en premier. Une requête par clic épuise les threads réseau du navigateur ; garder les événements trop longtemps risque de les perdre à la fermeture de l’onglet. Quand la page se ferme, il utilise navigator.sendBeacon.
• Un BFF qui valide. Les lots arrivent dans un Backend for Frontend qui vérifie le schéma par rapport aux définitions TypeScript, contrôle la cohérence des horodatages, supprime les champs inattendus et les données personnelles (PII), puis ajoute les métadonnées de session et le verdict du backend (validé, rejeté, en attente de revue). Comparer ce verdict à ce qu’affichait l’interface a révélé des écarts d’état entre l’interface et le backend.
• Kafka, Flink, ClickHouse, Grafana. Kafka absorbe les pics de trafic mondiaux, Flink traite les événements en temps réel, ClickHouse les stocke (le stockage en colonnes répond en quelques millisecondes à des agrégations sur des milliards d’événements à forte cardinalité, là où le stockage en lignes rampe) et Grafana affiche les tunnels.
• Une gestion discrète des pannes. Si le pipeline est hors service, le SDK conserve jusqu’à 100 événements dans localStorage et un disjoncteur passif suspend l’envoi. Il n’interroge pas le serveur pour vérifier son état ; il attend la prochaine réponse réussie.

Le résultat

Le délai de détection d’un incident est passé de 24 à 72 heures à moins de 5 minutes. Pour un tunnel où une étape fournisseur en panne signifie des milliers d’inscriptions échouées, c’est la différence entre une ligne dans un post-mortem et une correction le matin même.