Comment le CDC synchronise-t-il les données entre systèmes ?

Question

IT Interview Practice · Accepted Answer

**Le Change Data Capture (CDC)** streame chaque insert/update/delete hors d'une base de données source — typiquement en **lisant son transaction log** — et les publie comme des événements que d'autres systèmes consomment, pour que les stores en aval restent synchronisés sans dual-writes ni polling.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  reads   ┌─────────┐  emit   ┌──────────┐  consume ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-table│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordered │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## Pourquoi le CDC basé sur le log

Vous pourriez synchroniser par polling (« lignes changées depuis T ») ou en écrivant dans deux systèmes à la fois (**dual-write**), mais le polling manque les mises à jour rapides et les dual-writes cassent l'atomicité — si la seconde écriture échoue vous obtenez une divergence. Le **CDC basé sur le log** suit plutôt le write-ahead log de la base de données elle-même (Postgres **WAL**, MySQL **binlog**), l'enregistrement durable que la DB utilise pour la récupération après crash. **Debezium** est le connecteur standard : il lit le log et publie chaque changement vers **Kafka**, un topic par table — capturant *chaque* changement sans charge sur les requêtes et sans lignes manquées.

## Ordonnancement & idempotence

- **Ordonnancement :** les changements sur la même ligne doivent arriver dans l'ordre sinon vous appliqueriez une ancienne valeur en dernier. Kafka garantit l'ordre **au sein d'une partition**, donc partitionnez par primary key — tous les changements d'une ligne atterrissent sur une partition, dans l'ordre de commit.
- **La livraison est at-least-once :** lors d'un réessai ou d'un redémarrage du connecteur, le même événement peut être livré deux fois. Donc **les sinks doivent être idempotents** — indexez l'écriture par primary key + offset du log (LSN) pour que réappliquer un événement soit un no-op. Ne supposez jamais l'exactly-once.

## Perspective d'entretien

L'examinateur vérifie si vous savez que le CDC bat les dual-writes et *pourquoi* (atomicité, aucun changement manqué), et si vous saisissez l'**at-least-once + sinks idempotents**. Bien : « Debezium lit le WAL vers Kafka ». Excellent : vous ajoutez le partitionnement par clé pour l'ordre et les sinks idempotents pour les doublons. Piège : supposer une livraison exactly-once, ou ignorer qu'un changement DDL sur la source peut casser les consumers.

## Compromis et pannes

- **Évolution de schéma :** une colonne ajoutée/supprimée en amont change la forme de l'événement — utilisez un **schema registry** et des changements compatibles pour que les consumers ne cassent pas.
- **Snapshot initial :** le CDC ne voit que les changements *à partir de maintenant* ; vous avez besoin d'un snapshot unique des lignes existantes, puis passez au streaming.
- **Rétention du log :** si la source purge son log avant que le connecteur ne le lise, vous perdez des changements — monitorez le lag du connecteur.
- **Backpressure :** un sink lent laisse le lag Kafka croître ; dimensionnez la rétention et les consumers pour le volume de changements de pointe.

Pourquoi le CDC basé sur le log

Ordonnancement & idempotence

Perspective d'entretien

Compromis et pannes

Questions connexes