Logo Event-Driven Architecture Live

Arquitectura del CDC Pipeline

Real-Time Data Streaming

El streaming en tiempo real es el flujo continuo de datos a medida que se generan, permitiendo análisis y procesamiento inmediato para extraer información significativa.

Fuentes de datos comunes:

  • Actividad en sitios web

  • Transacciones bancarias

  • Compras de e-commerce

  • Actividad de jugadores en gaming

  • Sensores IoT

Change Data Capture (CDC)

CDC es un patrón de integración que identifica y captura cambios realizados en una base de datos (INSERT, UPDATE, DELETE) y los propaga como eventos a otros sistemas en tiempo real.

¿Por qué CDC?

Enfoque tradicional CDC con Debezium

Polling periódico a la DB

Captura basada en WAL (write-ahead log)

Alta latencia (segundos/minutos)

Latencia sub-segundo

Carga adicional en la DB

Impacto mínimo (lee el log de transacciones)

Puede perder cambios entre polls

Captura todos los cambios, incluyendo deletes

Arquitectura del Pipeline

Diagram

Flujo de datos detallado

  1. Un usuario inserta o actualiza un registro en PostgreSQL

  2. PostgreSQL escribe el cambio en el Write-Ahead Log (WAL) con wal_level=logical

  3. Debezium (corriendo como KafkaConnect plugin) lee el WAL via replication slot

  4. Debezium serializa el evento como JSON (opcionalmente Avro via Apicurio Registry)

  5. El evento se publica en el topic Kafka correspondiente (cdc.public.customers)

  6. Apache Camel consume el evento del topic

  7. Camel transforma el evento y envía una notificación por email via Mailpit

  8. Todo el pipeline es monitoreado en Grafana y visible en Kiali (Service Mesh)

How it Works

El pipeline CDC opera como una cadena reactiva de cinco etapas, donde cada componente actúa de forma independiente y asíncrona:

  1. Capture — PostgreSQL escribe cada transacción en el Write-Ahead Log (WAL) antes de confirmarla. Debezium abre un replication slot y lee el WAL usando el protocolo de replicación lógica nativa de PostgreSQL, sin queries adicionales a las tablas.

  2. Serialize — Debezium transforma cada cambio en un evento JSON estructurado que incluye: el valor before (estado previo del registro), after (estado nuevo), op (tipo de operación: c`reate, `u`pdate, `d`elete, `r`ead), y `source (metadata: tabla, schema, LSN, timestamp del WAL).

  3. Stream — El evento se publica en el topic Kafka correspondiente (cdc.public.<tabla>). Kafka lo persiste en disco, lo replica a 3 brokers (RF=3), y confirma el write solo cuando al menos 2 réplicas persisten el dato (min.insync.replicas=2).

  4. Process — Apache Camel consume del topic usando un consumer group. Cada partición se asigna a un solo consumidor (partition affinity), garantizando orden por primary key. Camel deserializa el JSON, aplica content-based routing ($.payload.op), y transforma el payload.

  5. React — El procesador Camel ejecuta la acción correspondiente: HTTP POST a Mailpit para notificaciones, producción a topics de DLQ para errores, o emisión de métricas Prometheus. Todo ocurre sin bloqueo — si un destino falla, el mensaje va a la Dead Letter Queue.

La latencia end-to-end típica del pipeline es sub-segundo desde el commit en PostgreSQL hasta la notificación. El cuello de botella no es Kafka (que persiste en microsegundos) sino el HTTP POST a servicios externos.

Namespace y recursos

Todos los componentes del CDC pipeline se despliegan en el namespace kafka-cdc:

apiVersion: v1
kind: Namespace
metadata:
  name: kafka-cdc
  labels:
    istio.io/dataplane-mode: ambient
    istio-discovery: enabled

El label istio.io/dataplane-mode: ambient enrolla automáticamente el namespace en el Service Mesh, haciendo visible todo el tráfico en Kiali sin necesidad de sidecars.

Alta Disponibilidad

El pipeline está configurado con múltiples réplicas y storage persistente para tolerancia a fallos.

Kafka Brokers — Storage Persistente

Los brokers usan persistent-claim en lugar de ephemeral para retener datos entre reinicios:

spec:
  kafka:
    replicas: 3
    storage:
      type: persistent-claim
      size: 10Gi
      deleteClaim: false

  • size: 10Gi — capacidad por broker (ajustar según volumen de datos)

  • deleteClaim: false — los PVCs se preservan al escalar o eliminar el cluster

KafkaConnect — 2 réplicas

KafkaConnect se despliega con 2 réplicas para balanceo de carga y failover de los connectors:

spec:
  replicas: 2

Kafka Connect distribuye automáticamente las tasks entre las réplicas disponibles. Si una réplica cae, la otra asume las tasks.

Camel CDC Processor — 2 réplicas

El procesador Camel se escala a 2 réplicas. Kafka balancea las particiones entre los consumidores del mismo group:

spec:
  replicas: 2

Con 3 particiones por topic y 2 consumidores, cada réplica procesa ~1.5 particiones en promedio.

Documentación Oficial