Une architecture Kafka de référence n’est pas une recette unique, mais un ensemble de principes qui garantissent disponibilité, résilience et gouvernance. En banque, Kafka devient souvent l’ossature du SI: il transporte des events comptables, des décisions de risque, des changements KYC et des notifications client. La conception doit donc intégrer la performance, la conformité et la traçabilité dès le départ.

Ce document présente une architecture de référence adaptée à un contexte bancaire, avec des choix concrets et leurs justifications.

Objectifs non fonctionnels

Avant de parler de brokers, clarifiez les objectifs: - Disponibilité: tolérance aux pannes, maintenance sans interruption. - Durabilité: aucun event perdu (notamment pour le ledger). - Traçabilité: audit et relecture longue durée. - Sécurité: chiffrement, contrôle d’accès, isolation des données sensibles. - Scalabilité: croissance contrôlée du débit et du stockage.

Ces objectifs conditionnent toutes les décisions techniques: replication factor, partitioning, rétention, politique de sécurité, et même la façon d’organiser les clusters.

Topologie de cluster

Une topologie de base robuste repose sur au moins 3 brokers. Ce seuil garantit un quorum et permet de résister à une panne sans perte de disponibilité. Pour des charges plus élevées, on augmente le nombre de brokers pour absorber le débit et le stockage.

En production bancaire, il est recommandé d’avoir: - 3 à 5 brokers par cluster critique. - 3 contrôleurs KRaft dédiés pour isoler le plan de contrôle. - Rack awareness pour répartir les réplicas sur des AZ différentes.

ZooKeeper vs KRaft

Kafka moderne bascule vers KRaft, basé sur Raft, qui remplace ZooKeeper. KRaft simplifie l’opérationnel, améliore la cohérence et réduit la dépendance externe. Si votre banque utilise encore ZooKeeper, planifiez une migration progressive: cluster KRaft parallèle, réplication inter-clusters, puis bascule contrôlée.

Réplication, ISR et disponibilité

La durabilité d’un event dépend de la réplication: - Replication factor 3 pour les topics critiques (ledger, paiements). - min.insync.replicas=2 pour forcer un quorum avant ACK. - unclean.leader.election.enable=false pour éviter les pertes silencieuses.

Ces paramètres augmentent la sécurité mais ajoutent un coût en latence. En banque, la perte d’un event comptable est inacceptable, donc on privilégie la fiabilité à la micro-latence.

Stockage, rétention et compaction

Kafka stocke des logs append-only segmentés. La stratégie de rétention dépend du besoin métier: - Ledger: rétention longue (années), parfois tiered storage. - Notifications: rétention courte (jours ou semaines). - Caches: compaction pour maintenir le dernier état.

En banque, la conformité impose souvent des durées longues. Utilisez une combinaison de rétention par temps et par taille, et configurez segment.bytes pour limiter l’impact des compactions. La compaction est idéale pour des topics qui portent un état (ex: position de compte), mais elle ne remplace pas un event log audit.

Sécurité et conformité

Kafka doit être traité comme un système sensible: - TLS pour chiffrer le transit. - SASL/SCRAM ou mTLS pour l’authentification. - ACL strictes par topic et par consumer group. - Chiffrement au repos et rotation de clés.

Segmentez les topics contenant des PII (IBAN, identité, KYC). En banque, une bonne pratique est de séparer les domaines sensibles dans un cluster dédié ou un namespace strict, avec des accès contrôlés par la conformité.

Protection des données et minimisation

La sécurité ne suffit pas si les données sont sur-exposées. Appliquez la minimisation: ne publiez que ce qui est nécessaire au traitement. Un event de paiement n’a pas besoin d’exposer l’identité complète du client si un identifiant pseudonymisé suffit. Pour les PII, privilégiez la tokenisation ou un chiffrement champ par champ, avec des clés gérées par un KMS central.

Dans un environnement bancaire, la conformité impose souvent des audits sur les accès et des politiques de rétention spécifiques aux données sensibles. Cela peut conduire à séparer certaines informations dans des systèmes spécialisés (vault, coffre-fort documentaire) et à publier uniquement des références dans Kafka. Cette approche réduit le risque et simplifie les exigences de purge selective (ex: droit à l’effacement, contraintes locales par pays).

Configuration producer (référence)

Les producteurs doivent maximiser la durabilité: - acks=all - enable.idempotence=true - retries élevé et delivery.timeout.ms suffisant - compression.type=snappy - batch.size=32768 et linger.ms=10

Exemple:

acks=all
enable.idempotence=true
compression.type=snappy
batch.size=32768
linger.ms=10
max.in.flight.requests.per.connection=5

Cette configuration équilibre fiabilité et latence. En banque, une latence de quelques millisecondes est un compromis acceptable pour garantir la durabilité.

Compression et tuning réseau

La compression doit être systématique: elle réduit la bande passante et le stockage, ce qui améliore la stabilité des brokers. Le choix dépend du compromis CPU/latence: snappy est souvent le meilleur équilibre, lz4 est très rapide pour des flux temps réel, tandis que zstd offre un taux de compression supérieur au prix d’un CPU plus élevé. Dans un contexte bancaire où les pics de charge sont fréquents (jour de paie, clôture), la compression permet de lisser le trafic sans surdimensionner excessivement.

Le tuning réseau passe aussi par le batching: batch.size et linger.ms déterminent combien de messages sont regroupés avant l’envoi. Un linger.ms modéré (10 ms) améliore la compression et l’efficacité réseau, tout en restant compatible avec des SLA transactionnels raisonnables. Ce réglage doit être testé avec des charges réalistes pour éviter les effets de latence inattendus.

Configuration consumer (référence)

Les consommateurs doivent garantir une lecture fiable et contrôlée: - Commit d’offset après traitement métier. - isolation.level=read_committed si vous utilisez les transactions. - Ajuster max.poll.interval.ms et max.poll.records pour éviter les timeouts.

Un consumer de ledger doit gérer l’idempotence en base: l’event est immuable, mais l’effet doit être unique. C’est ce mécanisme qui garantit la consistance métier, pas uniquement Kafka.

Gestion des erreurs, DLQ et replay

La stratégie d’erreur est un élément d’architecture. Distinguez erreurs métiers (solde insuffisant, KYC expiré) et erreurs techniques (timeout, payload invalide). Les erreurs métiers doivent produire un event explicite (TransferRejected) pour garantir l’auditabilité. Les erreurs techniques doivent être routées vers un flux de retry avec backoff, puis vers un DLQ si le traitement reste impossible.

Le reprocessing doit être contrôlé: conservez les headers (event_id, correlation_id, attempt), documentez la procédure, et limitez l’accès aux opérations de replay. En banque, une reprise non maîtrisée peut déclencher des vagues de notifications ou de recalculs de risque. Le replay doit donc être planifié et validé, comme une opération de production critique.

Design des topics et conventions

La lisibilité du SI dépend de conventions strictes. Adoptez une structure de nommage et une taxonomie claire: - Public vs private (contrat stable vs interne). - Fact vs delta (état complet ou changement minimal). - cmd vs evt (intention vs fait).

Modèles de nommage:

<environment>.<service>.<domain>.<action>.<version>
<environment>.<tenant>.<service>.<domain>.<action>.<version>
<environment>.<service>.<domain>.<type>.<action>.<version>

Bonnes pratiques de base

• prod.payments.transaction.evt.created.v1
• prod.payments.transaction.cmd.create.v1
• prod.corebanking.account.evt.opened.v1
• prod.mobilebanking.beneficiary.evt.confirmed.v1
• prod.payments.transaction.dlq.v1

La clé de partition doit refléter l’entité maître. Pour le ledger, account_id assure l’ordre des écritures. Si l’ordre n’est pas critique, null maximise la répartition mais supprime la garantie d’ordre.

Partitioning avancé et clés métier

La clé de partition est un choix structurant. Elle définit l’ordre des events et la façon dont la charge est distribuée sur le cluster. Une bonne pratique est d’utiliser une clé composée, par exemple:

account.ACC-001

Ce format rend explicite le type d’entité et facilite l’analyse. Dans un contexte bancaire, la clé doit préserver l’ordre sur les écritures d’un compte, sinon les projections de solde deviennent ambiguës. Si certains clients génèrent des volumes extrêmes, un sharding contrôlé (préfixes par région ou par segment) peut limiter les hotspots tout en conservant la logique métier.

Enfin, évitez les clés instables ou dérivées d’attributs volatiles. La stabilité de la clé garantit que les events resteront ordonnés dans le temps et que les consumers pourront rejouer sans surprises. C’est un détail technique, mais il conditionne directement la fiabilité du ledger.

Cycle de vie des topics

La création d’un topic doit être gouvernée. Chaque topic doit avoir un propriétaire, un schéma validé, une politique de rétention et un niveau de criticité. Sans cela, les clusters deviennent difficiles à opérer et les équipes perdent la visibilité sur les flux. La dépréciation est tout aussi importante. Définissez un processus: marquer le topic comme deprecated dans le catalogue, arrêter la production, attendre la fin de rétention, puis supprimer. En banque, il faut souvent conserver certains topics en lecture seule pour des raisons d’audit, même si la production est arrêtée. Le cycle de vie est donc un sujet à la fois technique et réglementaire.

Observabilité et opérations

Un cluster Kafka doit être monitoré en continu: - Lag par consumer group. - Utilisation CPU/disque, ISR instables. - Rebalances fréquents. - Temps de traitement end-to-end.

Mettez en place des alertes sur les métriques critiques et documentez des runbooks. En banque, la réactivité opérationnelle est essentielle, notamment sur les flux de paiement où un retard peut avoir des impacts réglementaires.

Opérations courantes et mises à jour

Les opérations Kafka doivent être prévisibles. Utilisez des upgrades progressifs (rolling upgrades), testez chaque version en staging, et évitez les migrations en production sans plan de rollback. Les reassignments de partitions doivent être planifiés hors périodes critiques pour limiter les rebalances.

Dans un contexte bancaire, les changements sont soumis à des processus de change management. Cela impose une discipline supplémentaire: fenêtres de maintenance, validation sécurité, et documentation détaillée. Un runbook clair sur la gestion d’un broker défaillant ou d’un topic saturé réduit le MTTR et limite l’impact client.

Capacité et dimensionnement

Le dimensionnement repose sur trois facteurs: débit, rétention et réplication. Une méthode simple consiste à: 1) Estimer le débit (messages/s, taille moyenne). 2) Multiplier par la rétention (ex: 7 jours). 3) Multiplier par le replication factor.

Ajoutez une marge de 30 à 50% pour l’évolution. Trop de partitions augmentent le coût des rebalances; trop peu limitent la scalabilité. En banque, il est souvent préférable de sur-provisionner légèrement pour éviter les migrations risquées.

Multi-cluster et disaster recovery

Les banques exigent souvent un plan DR avec un RTO/RPO strict. Deux options: - Active-passive: réplication vers un cluster standby. - Active-active: deux clusters synchronisés (plus complexe).

Kafka propose MirrorMaker 2 ou Cluster Linking pour la réplication. Le choix dépend des latences inter-régions et des obligations réglementaires. L’active-active impose un design idempotent et une gouvernance stricte des écritures concurrentes.

Gouvernance et séparation des environnements

Séparez strictement dev, staging et prod. Les quotas évitent les abus et la saturation du cluster. Chaque topic doit être documenté (owner, schéma, SLA, rétention). C’est un prérequis pour éviter les couplages invisibles.

La gouvernance ne s’arrête pas aux topics: elle englobe les schémas, les ACL, les plans de migration et les processus de décommissionnement. Sans cela, le cluster se transforme en point unique de dette technique.

Exemple d’architecture bancaire de référence

Un modèle fréquent dans les banques est le suivant: - Cluster transactionnel: paiements, ledger, KYC (RF=3, rétention longue). - Cluster analytique: data lake, reporting, fraude (rétention moyenne). - Cluster périphérique: notifications, temps réel (latence faible).

Les events critiques (ex: LedgerEntryPosted) sont produits dans le cluster transactionnel, puis répliqués vers l’analytique. Les projections de fraude et reporting sont construites sans impacter les systèmes transactionnels. Ce design isole les risques et réduit les impacts d’une surcharge analytique.

Conclusion

Une architecture Kafka de référence doit être pensée comme une infrastructure réglementaire autant que technique. En banque, la priorité est la durabilité et la traçabilité. Kafka peut fournir ces garanties si le design intègre dès le départ la réplication, la sécurité, la gouvernance et l’observabilité.