Le streaming permet de transformer les events en continu: agrégations, enrichissement, détection de patterns, et vues matérialisées. Kafka Streams et ksqlDB sont les outils courants. Dans une banque, le streaming est utilisé pour la fraude en temps réel, les tableaux de bord, ou la consolidation des soldes.

Cet article détaille les concepts essentiels (KStream, KTable, joins, fenêtrage), les pièges opérationnels et les bonnes pratiques en contexte bancaire.

Quand utiliser le streaming

• Tableaux de bord temps réel.
• Détection de fraude ou d’anomalies.
• Enrichissement par jointure avec un référentiel.
• Calcul de soldes ou agrégats continus.

Le streaming est pertinent lorsque l’on veut réagir aux événements en continu sans attendre des batchs.

KStream vs KTable

• KStream: flux d’événements immuables.
• KTable: table d’état dérivée, contenant la dernière valeur par clé.

Exemple bancaire: - Transactions cartes = KStream. - Profil client = KTable.

La jointure d’une transaction avec un profil client enrichit l’event avec des informations KYC, utiles pour le scoring fraude.

Opérations stateless vs stateful

• Stateless: map, filter, transform. Peu coûteux, pas de stockage.
• Stateful: joins, aggregations, dedup. Nécessite un state store.

En banque, les opérations stateful sont courantes (agrégation de montants, scoring, détection d’anomalies). Elles doivent être dimensionnées avec soin.

Joins et enrichissement

Stream-Stream join

Permet de corréler deux flux dans une fenêtre temporelle. Exemple: associer un paiement et une validation OTP.

Stream-Table join

Associe un event à l’état courant d’une table. Exemple: enrichir une transaction avec le statut KYC du client.

Table-Table join

Combine deux états. Exemple: croiser le profil client et la liste de bénéficiaires autorisés.

Fenêtrage (windowing)

Les agrégations en streaming s’appuient sur des fenêtres: - Tumbling window: fenêtres fixes, non chevauchantes. - Hopping window: fenêtres chevauchantes. - Sliding window: fenêtre glissante basée sur les événements.

Exemple bancaire: détecter des transactions multiples dans une fenêtre de 5 minutes pour identifier un comportement suspect.

Event-time vs processing-time

Le streaming doit choisir un temps de référence: - Event-time: basé sur occurred_at. - Processing-time: basé sur le moment de traitement.

En banque, l’event-time est privilégié pour la fraude et le reporting, car il reflète la réalité métier. Cela nécessite de gérer les events en retard.

Watermarking et dérive temporelle

Dans un flux réel, les events n’arrivent pas toujours dans l’ordre. Les plateformes de streaming utilisent un watermark pour définir jusqu’où on accepte les événements tardifs. Ce paramètre doit être aligné avec les canaux: un paiement mobile peut être plus tardif qu’un paiement carte.

Une mauvaise configuration peut soit rejeter des events légitimes, soit retarder excessivement les agrégations. L’équilibre dépend du SLA.

Fenêtres avancées: session windows et suppression

Les session windows regroupent des événements par périodes d’inactivité. Exemple bancaire: une série d’opérations en moins de 30 secondes peut être considérée comme une session de fraude.

La suppression (suppression until window closes) permet d’attendre la fin de la fenêtre avant d’émettre un résultat. Cela réduit le bruit mais augmente la latence. En banque, on choisit souvent un compromis pour éviter les faux positifs tout en maintenant la réactivité.

Déduplication en streaming

Un stream peut contenir des doublons. Kafka Streams permet de dédupliquer via un state store et un TTL (time-to-live). Exemple: ignorer les transactions déjà vues dans les 24 dernières heures. Cette stratégie est essentielle pour éviter de surévaluer les montants ou de déclencher des alertes injustifiées.

La déduplication nécessite un compromis: plus le TTL est long, plus le store grossit. Les banques dimensionnent ces stores en fonction des volumes et du risque métier.

Gestion des events tardifs

Kafka Streams permet de définir une grace period pour accepter les events arrivés en retard. Ce paramètre est critique: trop court, on perd des events; trop long, on augmente la latence des agrégations.

State stores et changelog topics

Les applications de streaming maintiennent un état local (state store). Cet état est répliqué dans un topic de changelog pour la tolérance aux pannes.

Dans une banque, la taille du state store doit être monitorée, car un store corrompu peut fausser un scoring fraude ou un solde temps réel.

Tuning des state stores

Les state stores reposent souvent sur RocksDB. Les paramètres à surveiller: - taille du store et taux de compaction, - latence d’accès, - taux de restauration après crash.

Un store trop gros augmente le temps de recovery. Les banques mettent en place des snapshots réguliers et monitorent les changelog topics pour éviter des restaurations excessives.

Repartitioning et coût réseau

Certaines opérations (joins, groupBy) exigent un repartition. Cela crée des topics intermédiaires. Il faut les dimensionner correctement et surveiller leur volume.

Une mauvaise stratégie de repartition peut augmenter la latence et la charge réseau.

Topology design et scalabilité

Une topologie de streaming doit être conçue pour le scaling horizontal: - partitions suffisantes sur les topics sources, - usage raisonné des repartitions, - équilibrage des tâches entre instances.

Dans un flux bancaire critique, on teste la topologie à charge réelle pour évaluer les goulets (joins lourds, state stores volumineux). La scalabilité doit être validée avant mise en production.

Vues matérialisées et CQRS

Le streaming permet de construire des vues matérialisées à partir des events. Ces vues alimentent les read models sans appels synchrones. En banque, on peut construire une vue des soldes en temps réel, distincte du ledger comptable. Cette séparation est un cas d’usage naturel de CQRS.

La qualité de ces vues dépend directement de la stabilité des streams et de la gestion des events tardifs. Une vue matérialisée doit toujours indiquer la fraîcheur de ses données.

Enrichissement externe et caches

Parfois, un stream doit être enrichi avec une donnée externe (score de risque, taux FX, statut KYC). Ces appels doivent être contrôlés pour éviter de bloquer le pipeline. Les patterns classiques: - cache local avec TTL, - KTable alimentée par un référentiel, - pré-calcul asynchrone.

Dans une banque, on évite autant que possible les appels synchrones en plein streaming. Ils augmentent la latence et créent des points de rupture.

Backpressure et contrôle des ressources

Un pipeline de streaming peut saturer CPU ou I/O. Kafka Streams propose un buffering interne, mais il faut surveiller la saturation. En banque, la stratégie consiste souvent à réduire le débit ou à mettre en pause certaines transformations non critiques.

Le backpressure doit être explicite: si un stream dépasse un seuil, on déclenche une alerte et on réduit la charge avant que le state store ne sature.

Sécurité et conformité du streaming

Les pipelines streaming manipulent des données sensibles. Les mesures recommandées: - chiffrement en transit, - ACLs strictes sur topics intermédiaires, - masquage des champs sensibles dans les logs.

En banque, les topics de changelog peuvent contenir des données PII et doivent être protégés comme les topics métiers. Ignorer cette dimension est un risque majeur.

Exactly-once semantics

Kafka Streams supporte l’exactly-once via transactions. Cela garantit que les agrégations ne comptent pas deux fois le même event. En banque, c’est essentiel pour les agrégats financiers.

Tests et validation des pipelines

Les pipelines de streaming doivent être testés de manière déterministe: - tests unitaires sur la logique de transformation, - tests d’intégration avec des flux réalistes, - tests de résilience (replay, crash, redémarrage).

En banque, ces tests permettent de garantir qu’un changement de topologie n’introduit pas de biais dans les calculs d’agrégats financiers.

Gouvernance des topics intermédiaires

Les opérations de streaming créent des topics internes (repartition, changelog). Il faut appliquer une gouvernance similaire aux topics métiers: rétention, compaction, ACLs. Sans cela, ces topics deviennent des points faibles en termes de coûts et de sécurité.

Interactive queries et serving layer

Kafka Streams permet d’exposer des interactive queries pour interroger un state store en temps réel. En banque, cela peut servir à exposer un solde “quasi temps réel” ou un score de fraude à faible latence. Cette approche réduit la charge sur les bases de données de lecture, mais elle impose une haute disponibilité des instances et un routage intelligent par clé.

Une alternative consiste à matérialiser les vues dans une base de lecture traditionnelle. L’arbitrage dépend du SLA: interactive queries offrent une latence minimale, mais demandent une rigueur d’exploitation élevée.

Déploiement et upgrades

Les pipelines de streaming doivent être mis à jour avec précaution. Un upgrade de topologie peut déclencher des repartitions et des replays coûteux. En banque, on pratique des déploiements progressifs (blue/green) et on valide les nouveaux pipelines sur un échantillon avant bascule complète.

Il est conseillé de versionner les applications de streaming (ex: risk-scoring-v2) pour permettre une coexistence temporaire et une migration contrôlée des consumers.

Évolution des schémas dans un pipeline streaming

Un pipeline de streaming est sensible aux changements de schéma. Une évolution incompatible peut invalider un state store ou provoquer des erreurs en chaîne. Dans une banque, il est recommandé de: - versionner les schémas et valider la compatibilité en CI, - planifier des migrations de store lors de changements majeurs, - rejouer un historique sur un pipeline de test avant déploiement.

Cette discipline évite les dérives silencieuses et garantit que les agrégations financières restent correctes malgré l’évolution des modèles métiers.

Bonnes pratiques de base

• Utiliser des topics dédiés pour les streams intermédiaires.
  • prod.risk.transfer.stream.raw.v1
  • prod.risk.transfer.stream.enriched.v1
• Activer l’exactly-once pour les agrégations financières.
• Surveiller la taille des state stores.

Exemple bancaire: scoring fraude temps réel

1) Stream des transactions cartes. 2) Join avec KTable des profils clients. 3) Agrégation par fenêtre de 5 minutes. 4) Publication d’un event TransactionFraudScored.

Ce pipeline permet de détecter des anomalies en quasi temps réel.

ksqlDB vs Kafka Streams

• Kafka Streams: librairie Java/Scala, contrôle total.
• ksqlDB: SQL streaming, plus accessible aux analystes.

Dans une banque, ksqlDB est souvent utilisé pour des cas d’usage exploratoires, Kafka Streams pour les pipelines critiques en production.

Observabilité et exploitation

Les métriques clés: - latence de traitement, - taille des state stores, - taux de reprocessing.

Un pipeline streaming doit être traité comme un service critique, avec monitoring et alertes dédiées.

Pièges à éviter

• Utiliser processing-time au lieu d’event-time pour des flux critiques.
• Ignorer les events tardifs.
• Sous-dimensionner les state stores.
• Oublier la gouvernance des topics intermédiaires.

Conclusion

Le streaming est un accélérateur puissant pour les architectures event-driven. Dans un contexte bancaire, il permet d’agir en temps réel sur les flux financiers, mais il impose une gouvernance stricte: event-time, idempotence, state stores et observabilité. Bien maîtrisé, il devient un levier majeur de résilience et de performance. Il doit être abordé comme un système critique, avec budgets d’erreur, tests de résilience et runbooks documentés. C’est le prix d’une réactivité bancaire fiable à grande échelle au quotidien opérationnel.