Réduire la latence & booster la fiabilité d’un système “event streaming”

1.Un système en perte de vitesse : constat et explications

1.1 Latence, Coûts Cachés et Frustration Utilisateur 

Dans les systèmes orientés “events streaming”, les conflits entre traitements en temps réel et batchs peuvent engendrer des lenteurs, des incidents et des pertes financières.

Dans ce contexte, nous avons été contactés par un client qui avait développé une application de souscription de couverture d’assurance crédit traitant quotidiennement des centaines de milliers de demandes clients, chacune représentant des montants allant de quelques milliers à plusieurs millions d’Euros. Ces demandes critiques pour les entreprises clientes conditionnent directement la faisabilité de transactions commerciales majeures. Un ralentissement de 2 à 3 minutes peut suffire à faire échouer une transaction de plusieurs millions d’Euros. À cette échelle, chaque seconde compte.

C’est pourquoi une grande partie des clients optent pour la souscription d’un service additionnel, leur garantissant une réponse automatique de l'application de souscription en quelques secondes. Le problème de ce type de solution est que le flux de données reçu est très important, rendant le respect du contrat très difficile. Il est donc impératif de mettre en place une solution technique adaptée pour optimiser ses résultats. L’objectif : éviter tout blocage susceptible d’entraîner une perte d’opportunité ou un décalage dans la prise de décision.

Dans un marché aussi concurrentiel que celui de l’assurance crédit, la performance perçue devient un facteur clé de fidélité. Chaque seconde de latence devient une friction, chaque indisponibilité fragilise la relation, surtout quand elle est naissante.

Ainsi, certaines entreprises ont vu leurs volume de demandes réduire progressivement, certainement réorientées vers des plateformes concurrentes. À ce niveau, la technique n’est plus un détail d’implémentation : elle devient un levier — ou un frein — business.

Cet article dévoile comment nous avons retravaillé l’architecture de ce système en adoptant un modèle double flux “multithreading”, et en mettant en place une observabilité avancée “monitoring” — avec des résultats mesurables à fort impact business.

1.2 Un contexte technique complexe entre migration cloud et stack étendue

L’entreprise d’assurance a entrepris une migration cloud stratégique, planifiée sur 10 ans, pour moderniser ses systèmes critiques — en particulier son application de souscription d’assurance crédit, jusqu’alors hébergé sur une infrastructure on-premise. Cette application, directement exposée aux clients via une interface web, devait impérativement maintenir un haut niveau de performance et de fluidité, sans rupture visible pour l’utilisateur.

L’infrastructure repose aujourd’hui sur une stack moderne mais distribuée, incluant :

• AWS ECS (Elastic Container Service) pour les services applicatifs
• AWS RDS (PostgreSQL) comme base de données cible
• AWS DMS pour migrer les données depuis une base IBM DB2
• AWS API Gateway pour sécuriser et exposer les services
• AWS Kinesis pour le traitement temps réel des événements
• Une application backend en Python, avec des requêtes PostgreSQL pour le calcul des décisions de couverture
• Terraform pour l’infrastructure as code
• Grafana et Prometheus pour le monitoring des métriques

Malgré une architecture globalement cohérente, la mise en production a révélé des limites importantes. Le manque de visibilité granulaire sur le fonctionnement de l’application — entre les volumes entrants, les temps de requêtes, la charge des conteneurs ECS, la performance des API ou encore les dépendances externes aux autres services et applications — rendait difficile l’identification rapide des goulets d’étranglement.

Le monitoring, pourtant cruciale dans ce type d’environnement distribué, était partiel. L’absence de corrélation fine entre les métriques empêchait une compréhension fluide de bout en bout, augmentant les temps d’investigation en cas d’incident — au détriment de la réactivité et de l’expérience client.

1.3 Un monitoring inadapté : comment diagnostiquer l’inexpliqué ?

L’un des enjeux majeurs d’un système distribué est la capacité à comprendre rapidement ce qui se passe en production. Dans le cas présent, l’absence de monitoring granulaire et transversal empêchait tout diagnostic fiable et rapide.
Résultat : approximation, incertitudes, et souvent une impossibilité pure et simple de localiser la source des lenteurs ou incidents.

Dans plusieurs cas, ce sont les utilisateurs eux-mêmes qui alertaient sur les ralentissements, révélant l’incident a posteriori. Cette situation dégrade directement leur expérience, érode la satisfaction client, et nuit à la fidélité dans un contexte déjà sous forte pression concurrentielle.

Impossible, par exemple, de corréler précisément :

• Le volume de transactions entrantes dans la RDS (via API Gateway ou DMS)
• La performance des requêtes SQL sur RDS
• la latence applicative Python dans les conteneurs ECS
• Le temps de traitement des événements dans Kinesis
• Le temps de réponse des dépendances externes d’autres services, tels que des call API

Ce manque de visibilité au cœur même de l’application ou de ses dépendances à d’autres services externes rendait l’identification des goulets d’étranglement lente, incertaine, et coûteuse. Chaque incident technique devenait une enquête manuelle fastidieuse, accaparant les équipes, allongeant les délais de résolution… et continuant d’impacter l’expérience client pendant toute la durée de l’investigation.

1.4 Goulot d'Étranglement : Quand le Traitement Séquentiel Plombe la Performance et le ROI

L’application de souscription ne se limite pas à la gestion des demandes individuelles en temps réel. Il doit également absorber des traitements lourds, comme les renouvellements massifs ou les modifications contractuelles à grande échelle. Problème : ces opérations sont exécutées dans un unique pipeline séquentiel, partagé avec les flux clients via l’interface utilisateur.

Cette architecture a rapidement montré ses limites. La cohabitation des traitements batchs et temps réel a engendré une concurrence directe pour les ressources du système, provoquant des ralentissements importants et une dégradation de l’expérience client. Le tout aggravé par un manque de visibilité sur les goulots d’étranglement internes et externes via les dépendances à l'application.

Conséquences directes :

• Retards sur les transactions en temps réel : latence moyenne de 5 minutes, due au blocage du pipeline par des batchs volumineux
• Incidents techniques quotidiens, entraînant une surcharge de travail pour les équipes
• Baisse de 15 % de la satisfaction client
• Pertes économiques estimées à 300 000 € par jour (souscription abandonnées)

Ces perturbations ont également un coût humain et organisationnel non négligeable. Les équipes techniques et opérationnelles, confrontées à des incidents répétés, ont vu leur productivité diminuer drastiquement. Le manque de monitoring rendait les investigations longues et peu concluantes, empêchant d’identifier clairement les causes racines. Les tâches répétitives liées à ces diagnostics manuels ont pesé sur la motivation des équipes, révélant la nécessité urgente de mettre en place des outils de supervision automatisés et intelligents.

Ce manque de priorisation des flux et de monitoring transverse constitue un risque structurel pour l’entreprise. Il ne s’agit pas uniquement d’un enjeu technique : il impacte directement la qualité de service perçue, la capacité à fidéliser les clients, et la compétitivité sur un marché hautement concurrentiel.

2.Comment une Architecture Double Flux et un Monitoring Avancé ont Transformé ce Système Événementiel

2.1 Architecture Multithreading : Séparer pour Mieux Traiter, Prioriser, et Scaler

La solution reposait sur un changement de paradigme : passer d’un traitement unique séquentiel à une architecture multithreading, capable de dissocier et prioriser intelligemment les flux.

L’application s’appuie sur la réplication logique de PostgreSQL, via un replication slot, pour recevoir en temps réel les transactions à traiter. À partir de là, elle génère des objets CloudEvent représentant les décisions de couverture.

Pour surmonter les goulots d’étranglement et prioriser les opérations critiques, deux threads consommateurs synchronisés ont été introduits. Ils lisent en parallèle le même flux logique, mais appliquent chacun une predicate métier exclusive et inverse :

• Thread batch : traite les volumes massifs (renouvellements, changements de contrat), sans contrainte de latence.
• Thread client temps réel : dédié aux demandes transactionnelles, avec un temps de réponse optimisé à 1,6 seconde (contre 5 minutes auparavant).

Chaque thread applique une règle métier opposée (P / ¬P) sur les mêmes événements, assurant une partition exclusive, exhaustive et sans recouvrement du flux. Résultat : un équilibrage parfait, sans double traitement ni perte d’événement.

En résumé : deux consommateurs synchrones, un flux partagé, une logique de filtrage inversée, et une orchestration fluide pour traiter en parallèle sans collision.

Objectifs techniques et business atteints :

• Dissociation claire des flux batch et temps réel
• Priorisation automatique des opérations critiques des clients
• Assurance d’un temps de réponse optimale respectant les SLA
• Nette amélioration de l’expérience utilisateur

2.2 Monitoring avancée : le levier invisible du succès

Si l’architecture multithreading a permis de résoudre les problèmes de latence, le monitoring a été le véritable garant de la pérennité, de la qualité et de la scalabilité de la solution. Plus de 70 % de l’effort projet a ainsi été consacré à l’instrumentation, à la traçabilité et à la mesure.

L’objectif : rendre visibles les points de friction, fiabiliser la production, et permettre une amélioration continue basée sur des données tangibles.

Cela s’est traduit par l’introduction de métriques précises et exploitables sur l’ensemble des composants de l’application — y compris les dépendances externes avec d’autres systèmes —, permettant une vision fine, de bout en bout, du comportement en production.

Un exemple concret : lisser le signal pour révéler l'essentiel

Au début du projet, l’analyse des flux entrants entre traitements batchs et demandes clients produisait des séries temporelles difficilement lisibles, du fait du volume élevé et de la fréquence soutenue des événements (>1 million de changements par jour, répartis sur >20 000 transactions et >300 000 CloudEvents quotidiens).

Une moyenne glissante sur une fenêtre de 5 minutes a d’abord été introduite pour lisser la courbe et rendre les tendances plus facilement interprétables. Cette première itération a permis une lecture simplifiée, mais a également masqué certains pics critiques : certaines transactions, bien que constantes en volume, étaient émises à une fréquence très élevée — ce qui ne ressortait pas sur la moyenne.

C’est alors qu’un second niveau de monitoring a été ajouté : une métrique de volume total par heure, en complément. Cette combinaison a permis de croiser les signaux (temps de réponse moyen, nombre de CloudEvents publiés, charge CPU, etc.) pour identifier les pics réels de flux, et mettre en œuvre des actions proactives — comme l’auto-scalabilité des ressources ou la priorisation dynamique des traitements.

Bénéfices observables immédiatement :

• Détection proactive des anomalies
• Analyse fine des causes racines
• Dashboards en temps réel pour les équipes produits et support
• Résolution d’incidents plus rapide et sans tâtonnement
• Baisse des tickets support → plus de temps pour l’innovation

Le monitoring est devenue un accélérateur de valeur pour l’IT et les métiers.

2.3 Résultats mesurables : un impact direct sur la performance, la qualité de service et la rentabilité

• Latence réduite de 98 % → de 5 minutes à 5 secondes
• Incidents quasi éliminés → de 1/jour à 1/mois
• Hausse de la note de satisfaction client → +20%
• Temps de résolution réduit à quelques minutes
• Charge support divisée, plus de focus produit
• Confiance et sérénité internes accrues

Ainsi , ce projet n’a pas simplement “réparé un système”, il a renforcé un produit stratégique, permis aux équipes de se recentrer sur la croissance et installé dès le premier contact client, un sentiment de confiance envers la marque. 

Conclusion : Une IT Orientée Performance et Résultats

Ce projet est la preuve qu’un bon design technique — pensé dès le départ pour la performance, le monitoring et son évolution — peut avoir un impact direct et mesurable sur le business, en très peu de temps.

L’introduction du multithreading a permis de désengorger le système et de redonner la priorité aux flux critiques. Mais ce qui a vraiment fait la différence sur le long terme, c’est le monitoring. On a pu tracer, mesurer, comprendre — et surtout anticiper. Grâce à des métriques bien choisies, visibles et actionnables, les équipes ont repris la main sur un système complexe, là où auparavant chaque incident devenait une course contre la montre.

La capacité à détecter les pics, à affiner les filtres, à lisser les courbes pour les rendre lisibles, ou encore à croiser les données pour révéler des patterns invisibles jusque-là… tout ça a changé la donne. Résultat : un système plus stable, une meilleure expérience client, et des équipes techniques beaucoup plus efficaces et alignées.

Vous avez des problèmes similaires et souhaitez avoir une approche orientée performance ?

Contactez nos experts pour un audit et une session conseil sur les architectures événementielles performantes, scalables, et pilotées par les métriques.