¿Cómo sincroniza CDC los datos entre sistemas?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** transmite cada insert/update/delete fuera de una base de datos de origen — típicamente **leyendo su transaction log** — y los publica como eventos que otros sistemas consumen, para que los stores aguas abajo permanezcan sincronizados sin 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     │
                                                                     └───────────┘
```

## Por qué CDC basado en log

Podrías sincronizar por polling ("filas cambiadas desde T") o escribiendo en dos sistemas a la vez (**dual-write**), pero el polling se pierde las actualizaciones rápidas y los dual-writes se rompen atómicamente — si la segunda escritura falla obtienes divergencia. El **CDC basado en log** en su lugar sigue el propio write-ahead log de la base de datos (Postgres **WAL**, MySQL **binlog**), el registro duradero que la DB usa para la recuperación ante crash. **Debezium** es el connector estándar: lee el log y publica cada cambio a **Kafka**, un topic por tabla — capturando *cada* cambio sin carga sobre las queries y sin filas perdidas.

## Ordenamiento e idempotencia

- **Ordenamiento:** los cambios a la misma fila deben llegar en orden o aplicarías un valor viejo al final. Kafka garantiza el orden **dentro de una partición**, así que particiona por primary key — todos los cambios de una fila aterrizan en una partición, en orden de commit.
- **La entrega es at-least-once:** ante un reintento o reinicio del connector el mismo evento puede entregarse dos veces. Así que **los sinks deben ser idempotentes** — indexa la escritura por primary key + log offset (LSN) para que re-aplicar un evento sea un no-op. Nunca asumas exactly-once.

## Perspectiva de la entrevista

El entrevistador comprueba si sabes que CDC le gana a los dual-writes y *por qué* (atomicidad, sin cambios perdidos), y si captas el **at-least-once + sinks idempotentes**. Bueno: "Debezium lee el WAL hacia Kafka." Excelente: añades particionado-por-clave para el orden y sinks idempotentes para los duplicados. Trampa: asumir entrega exactly-once, o ignorar que un cambio de DDL en el origen puede romper a los consumers.

## Compensaciones y modos de fallo

- **Evolución del schema:** una columna añadida/eliminada aguas arriba cambia la forma del evento — usa un **schema registry** y cambios compatibles para que los consumers no se rompan.
- **Snapshot inicial:** CDC solo ve los cambios *de ahora en adelante*; necesitas un snapshot único de las filas existentes, luego cambiar a streaming.
- **Retención del log:** si el origen purga su log antes de que el connector lo lea, pierdes cambios — monitorea el lag del connector.
- **Backpressure:** un sink lento deja crecer el lag de Kafka; dimensiona la retención y los consumers para el volumen de cambios pico.

Por qué CDC basado en log

Ordenamiento e idempotencia

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas