CDC pipeline (deep dive)

Un connector ne suffit pas : la chaîne CDC en production est faite d'un source connector, d'un schema registry, de transformations et de sink connectors, avec un monitoring lag dédié.

Problème

Le pattern CDC simple décrit la lecture du transaction log. En production, plusieurs choix s'imposent : initial snapshot blocking ou non, schéma binaire (Avro) ou JSON, partition par clé primaire ou par table, gestion de la suppression d'une row (tombstone Kafka), gestion des migrations DDL.

Forces

• L'initial snapshot d'une table 500 GB peut prendre des jours et bloquer le connector.
• Les schémas DB changent — il faut un schema registry pour ne pas casser les consommateurs.
• Les DELETE sont représentés par tombstones (key + null value) qui doivent être préservés.
• Le lag CDC peut diverger silencieusement si on ne le mesure pas.
• Une migration DDL (ALTER TABLE) peut bloquer le connector si mal anticipée.

Solution

Construire la chaîne en cinq étages : (1) source connector Debezium PostgreSQL / MySQL / Oracle ; (2) schema registry Confluent / Apicurio pour Avro / Protobuf ; (3) Single Message Transforms (filtrer, masquer PII, router par clé) ; (4) sink connectors vers cible (lake, ElasticSearch, autre DB) ou consommateurs custom ; (5) monitoring du lag avec debezium_metrics_milli_seconds_behind_source. Le snapshot initial doit être configuré (mode initial, schema_only, ou no_data selon l'usage).

Pipeline complet

Source DB (Postgres)
  │ logical replication slot
  ▼
┌─────────────────────────────────────────────────────┐
│ Debezium PostgreSQL Connector                       │
│   - reads WAL via pgoutput plugin                   │
│   - emits raw change events                         │
└─────────┬───────────────────────────────────────────┘
          │ Avro key+value
          ▼
┌─────────────────────────────────────────────────────┐
│ Kafka Connect Worker                                │
│   - SMT: ExtractNewRecordState                      │
│   - SMT: MaskField for PII                          │
│   - SMT: OutboxEventRouter                          │
└─────────┬───────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────────────┐
│ Kafka topics: db.public.orders, db.public.invoices  │
│   key = primary key (partitioning)                  │
└─────┬────────────────────────────┬──────────────────┘
      ▼                            ▼
 Consumer (EDI hub)        Sink: ElasticSearch
                            (Debezium ES sink)

Implémentation EDI

Cas Stellantis (mentionné publiquement en conférences Kafka Summit) : SAP ECC sur Oracle 19c, Debezium Oracle LogMiner sur les tables VBAP (ligne commande), LIKP (livraison) → transformations Kafka Streams qui assemblent un OrderConfirmed à partir des deltas → consommateur EDI qui publie un EDIFACT ORDRSP AS4 vers le fournisseur. Latence end-to-end ~ 2 s contre les batchs 6 h précédents. Le schema registry est crucial : un ajout de colonne SAP n'arrête pas la chaîne.

Anti-patterns

• Pas de schema registry — un breaking schema casse tous les consommateurs.
• Snapshot initial sans pacing — la base source sature.
• Tombstones ignorées par le consommateur — les DELETE ne se propagent pas.
• Filter Single Message Transform trop restrictif — perte silencieuse de données.
• Pas de monitoring du lag — la chaîne dérive sans alerte.

Patterns liés

• Change Data Capture — version synthétique.
• Transactional Outbox (deep dive) — CDC sur la table outbox est le combo standard.
• Pipes and Filters — le Kafka Connect SMT en est une instance.
• Event Message — produit en sortie.

Sources

• Debezium — Architecture documentation. debezium.io/documentation/reference/stable/architecture.html
• Confluent — Kafka Connect & Schema Registry. docs.confluent.io/platform/current/schema-registry/index.html
• Kreps J. — I Heart Logs: Event Data, Stream Processing, and Data Integration, O'Reilly 2014.