Entrevista de Ingeniería de Datos: Diseñar una Canalización de Change Data Capture (CDC)

Problema y Alcance

Una empresa tiene 20 bases de datos OLTP PostgreSQL, 200 tablas para sincronizar y 8 TB de datos actuales. Los orígenes producen un promedio de 20,000 cambios de filas confirmados por segundo y 60,000 en el pico. Un cambio codificado tiene un promedio de aproximadamente 1 KB. Los datos deben llegar a un almacén de datos analítico o lakehouse, con una latencia p99 desde la confirmación de la transacción de origen hasta los datos depurados consultables inferior a dos minutos. La sincronización inicial debe finalizar en 72 horas sin detener las escrituras de las aplicaciones, y la carga de trabajo de la instantánea más CDC debe causar menos del 5% de regresión en el p99 de escritura del origen.

La canalización debe manejar inserciones, actualizaciones, eliminaciones y cambios de valor de clave primaria. Debe preservar el orden de los cambios para una fila dentro de un mismo origen, usar entrega al menos una vez (at-least-once), admitir la evolución del esquema y el reprocesamiento por tabla o rango de claves primarias, recuperarse de fallas de origen y destino, y proporcionar reconciliación que pueda demostrar la exactitud. El flujo de cambios durable retiene siete días de eventos sin procesar, mientras que un almacenamiento de objetos de menor costo conserva un historial más prolongado. El recuento de bases de datos, el rendimiento, los tamaños, la latencia y los límites de recursos son suposiciones para la entrevista, no promesas de rendimiento de un producto.

Aunque el diseño contiene un broker y múltiples componentes, la habilidad fundamental es la ingeniería de datos: unir una instantánea almacenada a un flujo de cambios ilimitado sin vacíos, definir posiciones recuperables y límites de idempotencia, y demostrar que el destino no carece de datos ni es erróneo de forma silenciosa.

Qué Evalúan los Entrevistadores

La primera señal es definir la exactitud antes de dibujar componentes. Una respuesta débil comienza con "Debezium más Kafka". Una respuesta sólida establece invariantes: los cambios confirmados no pueden desaparecer, una fila debe converger en el orden de origen, los eventos reprocesados no pueden alterar el estado final, las eliminaciones deben llegar al destino, el límite entre la instantánea y el flujo no puede tener un vacío, y una posición de recuperación incierta debe fallar de forma cerrada (fail closed) en lugar de continuar silenciosamente.

La segunda señal es comprender que una instantánea inicial no es "exportar todas las tablas y luego habilitar CDC". Las escrituras continúan durante una exportación de 8 TB. Si la captura del WAL comienza solo después de la exportación, es posible que los cambios intermedios ya hayan desaparecido. Un diseño confiable establece una posición de registro recuperable y un mecanismo de retención antes o al momento en que adquiere una instantánea consistente, luego transmite los cambios confirmados a partir de la posición coincidente. Un conector puede encapsular el procedimiento, pero el candidato aún debe explicar por qué la transición no tiene vacíos.

La tercera señal es mantener la entrega al menos una vez hasta el destino final (sink). Un conector puede fallar después de emitir duraderamente un evento pero antes de registrar su desplazamiento (offset) de origen. Un lote del almacén de datos puede confirmarse mientras se pierde su confirmación de recepción (acknowledgement). "Exactamente una vez en el broker" no incluye automáticamente un almacén de datos externo. Las respuestas sólidas adjuntan la identidad de origen, la posición de origen y el orden de la transacción a cada evento, y luego aplican un evento solo cuando su versión es más reciente que la versión ya registrada para esa fila.

La cuarta señal es reconocer el riesgo bidireccional de los slots de replicación de PostgreSQL. Un slot le permite al conector reanudarse desde un LSN, pero también retiene el WAL mientras el conector se retrasa. Sin alertas de bytes retenidos y margen de espacio en disco, una interrupción del destino puede eventualmente llenar el almacenamiento de origen. Si se elimina y recrea un slot, el nuevo slot no puede reproducir la posición anterior. La canalización debe detenerse, reconciliarse o volver a tomar una instantánea en lugar de continuar "desde ahora" y afirmar que no se perdió nada.

Finalmente, la respuesta debe cubrir la semántica real de los datos. Un evento de eliminación de negocio difiere de un tombstone utilizado para la compactación de registros. Una actualización del valor de la clave primaria comúnmente aparece como una eliminación para la clave antigua y una creación para la nueva clave. Los LSN de bases de datos independientes no se pueden comparar. Si los consumidores necesitan visibilidad atómica para cada fila en una transacción de múltiples filas, el diseño debe usar metadatos de límites de transacción y aceptar búferes adicionales, latencia y complejidad de recuperación.

Preguntas para Aclarar Antes de Responder

• ¿El destino necesita el estado actual, el historial completo de cambios o ambos? El estado actual se ajusta a las operaciones MERGE de clave primaria. La auditoría y el reprocesamiento también requieren una capa inmutable de cambios sin procesar. El estado final por sí solo no puede reconstruir el historial.
• ¿Dónde inicia y termina el reloj de latencia de dos minutos? Este problema se mide desde la confirmación de la transacción de origen hasta los datos depurados consultables. Un requisito que se detenga cuando el evento sin procesar ingresa al broker es mucho más sencillo.
• ¿Una transacción de múltiples tablas debe hacerse visible de forma atómica? El valor predeterminado aquí es el ordenamiento por fila con una breve visibilidad parcial en el almacén de datos. Un consumidor financiero que requiera atomicidad para toda la transacción necesita el ensamblaje de BEGIN/END.
• ¿Cada tabla tiene una clave primaria estable? Sin una, localizar y deduplicar eventos de UPDATE y DELETE es más difícil. Se debe agregar una clave de negocio o aceptar explícitamente la identidad de fila completa, claves subrogadas y un mayor costo de almacenamiento.
• ¿La conmutación por error (failover) del origen preserva los slots de replicación lógica? Si no es así, la recuperación necesita una pausa controlada de escritura, verificación del último LSN, recreación del slot y reconciliación. Un failover del primario no puede tratarse como una reconexión ordinaria.
• ¿Qué cambios de esquema pueden pasar automáticamente? Este diseño acepta automáticamente cambios compatibles, como agregar una columna que admita valores nulos. Las eliminaciones, cambios de nombre, reducciones de tipos y cambios de clave primaria utilizan migraciones controladas.
• ¿Qué es más difícil, el plazo de instantánea de 72 horas o el presupuesto del 5% del origen? Leer 8 TB en 72 horas requiere aproximadamente 30.9 MB/s de rendimiento efectivo agregado. Si las pruebas de carga muestran que esto supera el presupuesto del origen, extiende el plazo, usa una réplica semánticamente válida o reduce el alcance por fases.
• ¿Cuánto tiempo debe absorber el flujo en línea una interrupción del destino? Este diseño cubre una interrupción máxima de 30 minutos en línea. El flujo durable de siete días y el archivo de objetos manejan reprocesamientos más prolongados.

Respuesta de 30 Segundos

"Definiría la exactitud primero: la instantánea y el flujo no tienen vacíos, una fila converge según la posición de origen, el reprocesamiento es seguro, las eliminaciones se propagan y la pérdida del historial de un slot de replicación falla de forma cerrada. Cada origen de PostgreSQL utiliza decodificación lógica sobre el WAL, toma una instantánea consistente y se reanuda desde el LSN correspondiente. Los eventos se particionan por origen, tabla y clave primaria en un flujo durable. La capa sin procesar permanece inmutable, mientras que el destino depurado realiza operaciones MERGE idempotentes por clave primaria y versión de origen. La compatibilidad del esquema se verifica antes de la aplicación, y las eliminaciones y cambios de clave son explícitos. Monitorearía la frescura segmentada, el retraso de LSN, el WAL retenido, el progreso de la instantánea y las diferencias de reconciliación; luego inyectaría fallas del conector, pérdida de slots, cambios de esquema e interrupciones del destino."

Análisis Paso a Paso en Profundidad

Paso 1: Dimensionar el búfer, la instantánea y el presupuesto de recuperación

La carga promedio es:

20,000 events/s × 1 KB ≈ 20 MB/s
20,000 × 86,400 = 1,728,000,000 events/day
20 MB/s × 86,400 ≈ 1.728 TB/day

El ingreso máximo es de aproximadamente 60 MB/s. Si el destino se detiene durante 30 minutos en el pico, la acumulación (backlog) de datos sin procesar es aproximadamente:

60 MB/s × 1,800 seconds = 108 GB

Siete días a la tasa promedio representan alrededor de 12.096 TB de datos sin procesar antes de la replicación, los índices y la sobrecarga de codificación. Dimensiona el broker, el almacenamiento de objetos y la red para el tráfico pico y la recuperación del retraso, no solo para el promedio de 20 MB/s. Si el consumidor recuperado solo puede igualar la tasa de entrada en vivo, nunca eliminará la acumulación de 108 GB; el diseño necesita capacidad de consumo de reserva o una flexibilización temporal de la latencia en la capa depurada.

Finalizar una instantánea de 8 TB en 72 horas requiere al menos:

8 TB ÷ 72 hours ≈ 30.9 MB/s

Ese es un límite inferior que excluye la amplificación de lectura, la serialización, los reintentos de red y las escrituras en el destino. Realiza pruebas de rendimiento (benchmark) de instantáneas por fragmentos (chunks) en datos con forma de producción, luego aplica límites de tasa según la E/S del origen, el comportamiento de la memoria caché, el retraso de replicación y el p99. Si el plazo entra en conflicto con el presupuesto del 5% del origen, cambia el plazo o la ruta de origen en lugar de sobrecargar el OLTP.

Paso 2: Hacer que cada componente responda a una necesidad de exactitud o capacidad

El flujo de datos principal es:

PostgreSQL WAL / logical slot
  → source connector
  → durable change stream keyed by source + table + primary key
  → immutable raw archive
  → schema validation and light normalization
  → sink staging tables
  → idempotent MERGE / DELETE into curated tables
  → warehouse and lakehouse consumers

Asigna a cada base de datos de origen su propio identificador de origen, conector y slot de replicación para que un dominio de falla no detenga todos los orígenes. El flujo durable absorbe ráfagas, desacopla a los consumidores y admite el reprocesamiento a corto plazo. El almacenamiento de objetos conserva un historial más prolongado. Mantén la capa de procesamiento de CDC limitada a la validación de esquemas, normalización y enrutamiento; una búsqueda externa no reproducible en la ruta principal dificulta la recuperación. Escribe en el almacén de datos a través de tablas de staging y pequeños lotes atómicos de MERGE para equilibrar un SLA de dos minutos con escrituras columnares eficientes.

Utiliza una codificación estable de (source_id, table_id, primary_key) como clave de partición para que los cambios de una fila lleguen a una sola partición ordenada. Esto no proporciona un orden global, y el orden global es innecesario. Las 20 bases de datos de origen tienen secuencias de LSN independientes cuyos valores numéricos no tienen significado cruzado entre orígenes.

Paso 3: Realizar la instantánea inicial en línea con escrituras activas

La secuencia lógica es:

1. Establecer un slot de replicación lógica para que el WAL requerido no se pueda reciclar antes de que el conector lo consuma.
2. Adquirir una instantánea consistente y su correspondiente posición en el registro de origen.
3. Leer la instantánea en fragmentos de tabla y clave primaria, emitiendo las filas actuales como eventos READ.
4. Transmitir registros de INSERT, UPDATE y DELETE confirmados desde la posición asociada con la instantánea.
5. Permitir que el destino converja por versión de origen, admitiendo el reprocesamiento de límites durante la recuperación pero sin permitir nunca un intervalo faltante.

Un conector puede implementar una instantánea consistente completa o ventanas de instantáneas incrementales. La respuesta no debe inventar un protocolo de "registrar un LSN y luego ejecutar sentencias SELECT ordinarias", porque el aislamiento, las transacciones largas y las escrituras simultáneas lo hacen engañosamente complejo. Confía en la semántica verificada del conector y prueba una clave primaria que se actualiza, elimina y recrea repetidamente mientras se ejecuta su fragmento de instantánea.

Divide en fragmentos por rango de clave primaria y persiste el progreso. Los fragmentos más pequeños reducen las transacciones largas, la alteración de la caché y el retrabajo ante fallas; los fragmentos excesivamente pequeños agregan sobrecarga de consultas y planificación. Limita la tasa de cada origen de forma independiente, establece confianza de extremo a extremo primero con tablas pequeñas y luego procesa tablas grandes. El conector debe continuar drenando el WAL durante la instantánea o el WAL retenido crecerá. Si el conector seleccionado no admite cambios de esquema durante una instantánea incremental, congela el DDL para esa tabla o pausa su instantánea.

Paso 4: Definir el evento, el ordenamiento y la aplicación idempotente

Un evento normalizado incluye al menos:

ChangeEvent {
  event_id
  source_id
  table_id
  primary_key
  operation          // READ | CREATE | UPDATE | DELETE
  before
  after
  source_lsn
  transaction_id
  transaction_order
  source_commit_time
  schema_version
  captured_at
}

Dentro de un origen, source_lsn más el orden de la transacción establece el orden de los eventos. La clave de versión debe incluir source_id porque los LSN de diferentes bases de datos no comparten un sistema de coordenadas. Para cada (source_id, table_id, primary_key), el destino almacena la última versión de origen aplicada. El destino confirma una versión igual o más antigua sin modificar la fila. Una versión más reciente actualiza tanto la fila de negocio como la versión aplicada en una sola transacción de destino.

Esto hace que las principales ventanas de falla de "al menos una vez" sean manejables:

• El evento llega al flujo durable pero su desplazamiento de origen no se registra: la recuperación lo vuelve a emitir y el destino ignora la versión igual.
• El MERGE de destino se confirma pero se pierde la confirmación de recepción: el lote se reprocesa y converge al mismo estado.
• El consumidor falla a mitad de un lote: las filas confirmadas se reprocesan de forma segura y las filas no confirmadas se procesan nuevamente.

Si el destino requiere atomicidad de transacciones de múltiples filas, habilita los metadatos de límites de transacción y almacena en búfer por transaction_id hasta END, luego confirma la transacción completa junta. Las transacciones grandes consumen más memoria y aumentan la latencia de cola, y la lógica de tiempo de espera (timeout) o recuperación debe determinar si una transacción está completa. Un almacén de datos analítico normal que necesita consistencia eventual a nivel de fila no debe aceptar esta complejidad sin un requisito real.

Paso 5: Manejar correctamente eliminaciones, cambios de clave y evolución de esquemas

Un evento DELETE debe llevar suficiente información de clave para que la capa depurada elimine la fila permanentemente (hard-delete), establezca is_deleted o preserve el historial. Un tombstone que sigue a una eliminación respalda principalmente la compactación de registros. No puede reemplazar el evento de eliminación de negocio, y el middleware no debe descartar la eliminación antes de que llegue al destino.

Cuando cambia el valor de una clave primaria, la semántica común de CDC emite una eliminación para la clave antigua y una creación para la nueva clave. El destino debe aplicar ambas o la clave antigua permanecerá como una fila fantasma. Cambiar la definición de la clave primaria es más riesgoso que cambiar un valor. Utiliza una ventana de solo lectura o de pausa de escritura, drena el conector, actualiza el esquema y luego reanuda, ya que la estructura de la clave del evento puede ser inconsistente durante la transición.

Utiliza una política de compatibilidad explícita:

• Columna agregada que admite valores nulos: registra una nueva versión, permite que los consumidores antiguos ignoren el campo desconocido, amplía la tabla depurada antes de habilitar las escrituras.
• Columna eliminada o renombrada: introduce y llena el nuevo campo, migra todos los consumidores y luego elimina el campo antiguo.
• Tipo ampliado: actualiza después de las comprobaciones de compatibilidad del destino. Los tipos reducidos o los cambios semánticos ponen en cuarentena los eventos incompatibles.
• Cambio de clave primaria: manéjalo como una migración independiente en lugar de una evolución automática silenciosa.

Un evento incompatible entra en cuarentena y genera una alerta. El desplazamiento principal puede avanzar solo después de que el evento se almacene de forma durable, sea reproducible y se le asigne un responsable claro de corrección. Omitir silenciosamente un esquema defectuoso crea un vacío de datos invisible.

Paso 6: Tratar la recuperación, el reprocesamiento y la reconciliación como rutas normales

La recuperación del conector requiere tanto un desplazamiento persistido como un slot de replicación que aún contenga el historial correspondiente. Monitorea restart_lsn, confirmed_flush_lsn, la posición actual del WAL, los bytes retenidos, la tasa de crecimiento y el tiempo hasta agotar el disco. Una interrupción del destino debe acumularse en el flujo durable en lugar de detener la confirmación del conector el tiempo suficiente para retener WAL ilimitado en el origen.

Si falta el slot, el desplazamiento almacenado está detrás de la posición disponible del slot o el WAL requerido ha desaparecido, falla de forma cerrada. Detén la publicación depurada para ese origen, registra la última posición de confianza, vuelve a tomar una instantánea de las tablas afectadas y reconcilia por rango. Un slot recién creado captura solo los cambios posteriores a su creación y no puede demostrar que el intervalo anterior esté completo.

El reprocesamiento tiene su propio replay_job_id, alcance de tabla y clave primaria, y límite de tiempo de origen. Lee la capa sin procesar inmutable hacia el área de staging. Los datos en vivo y reprocesados utilizan la misma regla MERGE de versión de origen para que una recarga (backfill) más antigua no pueda sobrescribir un estado más nuevo. Cuando la lógica de transformación cambie, construye primero una nueva versión depurada o una tabla espejo (shadow table); comparar y revertir es más seguro que sobrescribir producción de inmediato.

La reconciliación cubre al menos cuatro capas:

1. Continuidad desde la posición de confirmación de origen hasta el conector, el flujo durable y la posición aplicada en el destino.
2. Recuentos de filas, recuentos de eliminaciones y sumas de verificación (checksums) por tabla, fecha y bloque de claves primarias.
3. Comparaciones muestreadas de claves primarias entre el estado actual del origen y el estado más reciente del destino.
4. Transacciones testigo (canary) periódicas e identificables que verifiquen la visibilidad de INSERT, UPDATE y DELETE dentro del SLA.

Desglosa la latencia de extremo a extremo en: confirmación de origen a captura, captura a flujo, flujo a staging y staging a depurado. Además, monitorea la tasa de eventos por origen, el retraso de LSN, el WAL del slot retenido, el progreso de fragmentos de instantáneas, versiones duplicadas u obsoletas, cuarentena de esquemas, fallas de MERGE en el destino, diferencias de reconciliación y el tiempo estimado de puesta al día.

Paso 7: Explicar los límites de las alternativas

El sondeo (polling) por updated_at es simple para tablas con pocas escrituras, frescura de nivel de minutos y reescaneos aceptables. Agrega carga de consultas, pierde fácilmente las eliminaciones físicas y aún debe manejar marcas de tiempo iguales y precisión de reloj. Los disparadores (triggers) pueden escribir eliminaciones en una tabla de auditoría, pero agregan trabajo y acoplamiento operativo a la ruta de escritura del origen. El CDC basado en registros es la mejor opción predeterminada para la carga de trabajo OLTP intensa de este problema.

El patrón outbox resuelve un problema diferente: un servicio escribe el estado de negocio y un evento de dominio en una sola transacción de base de datos, evitando una confirmación exitosa de la base de datos seguida de un envío fallido del mensaje. Es apropiado para eventos de negocio seleccionados. No reemplaza automáticamente la sincronización genérica a nivel de fila para 200 tablas. Ambos pueden coexistir: la integración de servicios consume el outbox, mientras que la analítica y la auditoría consumen el CDC.

Respuesta de Ejemplo Sólida

"Comenzaría con las garantías. Cada cambio confirmado que aún exista en el WAL o en el flujo durable debe ser recuperable. Una fila converge por posición de origen, el reprocesamiento no altera su estado final y las eliminaciones llegan al destino. Si el slot de replicación y la posición histórica ya no están intactos, la publicación se detiene y se toma una nueva instantánea de los datos afectados; el conector no puede reiniciarse silenciosamente en la posición más reciente.

Con una carga promedio, el ingreso es de aproximadamente 20 MB/s, 1.728 mil millones de eventos y 1.728 TB por día. El pico es de 60 MB/s, por lo que una interrupción del destino de 30 minutos crea una acumulación de aproximadamente 108 GB. La retención de datos sin procesar durante siete días es de unos 12.096 TB. La instantánea de 8 TB necesita al menos 30.9 MB/s de lectura efectiva para finalizar en 72 horas, por lo que realizaría pruebas de rendimiento y limitaría la tasa de cada origen por p99, E/S y WAL retenido.

Cada origen de PostgreSQL obtiene un slot lógico y un conector independientes. El conector toma una instantánea consistente y luego reanuda los cambios confirmados a partir del LSN correspondiente. Los eventos se particionan por origen, tabla y clave primaria en un flujo durable y se copian en una capa sin procesar inmutable. Un procesamiento ligero valida el esquema y normaliza la estructura del evento (envelope). El almacén de datos carga tablas de staging y luego realiza operaciones MERGE o DELETE idempotentes por clave primaria y versión de origen. Los LSN nunca se comparan entre bases de datos; el orden de las transacciones complementa al LSN dentro de una transacción.

La instantánea se divide en fragmentos por rango de clave primaria, el progreso se persiste y la carga de origen se limita dinámicamente. El WAL se drena mientras se ejecuta la instantánea, y la regla de versión de origen del destino absorbe el reprocesamiento de recuperación en el límite. Los eventos contienen la operación, los valores anteriores y posteriores, el LSN de origen, la identidad y el orden de la transacción, y la versión del esquema. El destino aplica solo una versión más reciente, por lo que el reprocesamiento del conector, una confirmación de recepción perdida en el destino y las fallas de consumidores convergen de manera segura.

Los eventos de eliminación permanecen intactos a través de la capa depurada; los tombstones son solo para la compactación. Un cambio en el valor de la clave primaria se aplica como una eliminación de la clave antigua más la creación de una clave nueva. Las columnas agregadas que admiten valores nulos pueden evolucionar de forma compatible, mientras que las eliminaciones, cambios de nombre, reducción de tipos y cambios de claves utilizan migraciones controladas. Los registros incompatibles se ponen en cuarentena y son reproducibles en lugar de omitirse silenciosamente.

Operativamente, monitorearía la latencia segmentada, el retraso de LSN por origen, el WAL retenido por slot y el margen de disco, el progreso de las instantáneas, la cuarentena de esquemas, las fallas de destino y las diferencias de reconciliación. La pérdida de slots falla de forma cerrada y activa una nueva instantánea del alcance afectado. Finalmente, inyectaría escrituras concurrentes durante la instantánea, entrega duplicada, eliminaciones, cambios de claves, fallas del conector, confirmaciones de recepción perdidas en el destino, una interrupción del destino de 30 minutos, pérdida de slots y cambios de esquema incompatibles. Los recuentos de filas, los checksums de bloques de claves, las filas muestreadas y las transacciones testigo demostrarían que no falta ningún cambio y que ningún evento obsoleto sobrescribe un estado más nuevo."

Errores Comunes

• Exportar cada tabla y habilitar CDC solo después → El WAL del intervalo de exportación puede desaparecer, dejando un vacío entre la instantánea y el flujo → Establece la retención de registros y una posición de instantánea consistente antes de transmitir desde el punto coincidente.
• Decir solo "usar Debezium y Kafka" → Los nombres de productos no definen la latencia, el ordenamiento, la recuperación o la idempotencia en el destino → Declara primero las invariantes de exactitud y la capacidad, luego asigna cada componente a ellas.
• Comparar los LSN de diferentes bases de datos como una sola versión global → Cada origen tiene una coordenada de registro independiente → Incluye source_id en la versión y compara posiciones solo dentro de la secuencia de un solo origen.
• Asumir que el procesamiento de exactamente una vez del broker hace que el almacén de datos sea de exactamente una vez → Un MERGE externo puede ubicarse fuera de la transacción del broker y reprocesarse tras perderse una confirmación de recepción → Aplica cambios de forma idempotente por clave primaria y versión de origen.
• Esperar indefinidamente a un conector detenido → Su slot puede retener el WAL hasta que el almacenamiento de origen se llene → Monitorea los bytes retenidos y el tiempo hasta el agotamiento, aísla las interrupciones del destino con el flujo durable y establece umbrales de detención de pérdidas (stop-loss).
• Recrear un slot perdido y continuar en la posición más reciente → El nuevo slot no tiene historial previo y puede ocultar datos faltantes → Falla de forma cerrada, vuelve a tomar una instantánea y reconcilia el alcance afectado.
• Tratar el tombstone como la única señal de eliminación → Un marcador de compactación no puede reemplazar un DELETE de negocio que lleva la clave de la fila → Preserva el evento de eliminación y elige eliminación física, eliminación lógica o historial en el destino.
• Aceptar automáticamente cada cambio de esquema → Las eliminaciones, reducción de tipos y cambios de clave pueden romper consumidores o claves de eventos → Define una matriz de compatibilidad, pon en cuarentena los registros incompatibles y planifica las migraciones disruptivas por fases.
• Optimizar únicamente para el plazo de instantánea de 72 horas → Un escaneo grande puede perjudicar el p99 del origen, el comportamiento de la caché y la replicación → Evalúa el límite inferior de 30.9 MB/s, aplica límites de tasa dinámicamente y protege el presupuesto del origen.
• Comparar solo los recuentos totales de filas → Las actualizaciones mal aplicadas, las eliminaciones no registradas y los errores de compensación mutua pueden permanecer ocultos → Compara recuentos y sumas de verificación por bloque de claves, realiza muestreos de filas e inyecta transacciones testigo.

Preguntas de Seguimiento

Pregunta de seguimiento 1: ¿Cómo demuestras que una actualización y eliminación durante la instantánea no pueden permitir que un valor antiguo de la instantánea sobrescriba el nuevo estado?

Utiliza la semántica verificada del conector para instantáneas consistentes y transferencia de registros en lugar de suponer los tiempos de la aplicación. El destino almacena una versión de origen por fila y solo acepta versiones más recientes, por lo que un READ reprocesado no puede sobrescribir un UPDATE o DELETE más reciente. En las pruebas, actualiza, elimina y recrea repetidamente una clave en torno a su fragmento de instantánea, luego verifica la igualdad final entre el origen y el destino y la continuidad de la posición de origen.

Pregunta de seguimiento 2: ¿Cómo estimas el tiempo de recuperación después de una interrupción de 30 minutos del almacén de datos?

La acumulación máxima es de aproximadamente 108 GB. El tiempo de recuperación depende del rendimiento recuperado menos la tasa de entrada en vivo continua. Si el tráfico en vivo regresa al promedio de 20 MB/s y los consumidores sostienen 80 MB/s, la tasa neta de recuperación es de aproximadamente 60 MB/s, lo que hace que el tiempo teórico de vaciado sea de unos 30 minutos antes de la amplificación de MERGE y el margen de seguridad. Si el procesamiento solo iguala la entrada en vivo, la acumulación nunca se reduce.

Pregunta de seguimiento 3: ¿Qué cambia si todas las filas de una transacción de origen deben hacerse visibles juntas?

Habilita los metadatos de límites de transacción, ensambla los eventos por ID de transacción y confirma la transacción en staging y publicación solo después de un límite END completo. Persiste transacciones grandes en disco, define rutas de tiempo de espera y remediación, y reanuda desde el estado de ensamblaje durable. Esto aumenta la latencia de cola y el costo del estado, así que primero confirma si una inconsistencia breve entre tablas es verdaderamente inaceptable para el consumidor.

Pregunta de seguimiento 4: Si se pierde el slot de replicación pero el flujo durable todavía tiene siete días de datos, ¿debes ejecutar una instantánea completa?

Primero localiza el posible vacío. Si se puede demostrar que el flujo durable contiene cada cambio posterior al último LSN confiable, el reprocesamiento y la reconciliación pueden restaurar la continuidad sin una instantánea completa. Si el slot desapareció antes de que los eventos llegaran al flujo, o no se puede demostrar el límite del vacío, vuelve a tomar una instantánea de las tablas o rangos de clave primaria afectados. La decisión se basa en la continuidad demostrable, no en el costo del retrabajo.

Pregunta de seguimiento 5: ¿Por qué no reemplazar todo el diseño con un outbox?

Un outbox es excelente cuando un servicio publica explícitamente eventos de dominio como orden-creada o pago-completado y escribe el evento en la misma transacción que el estado del negocio. Requiere la participación de la aplicación y contiene solo hechos seleccionados. Este problema sincroniza inserciones, actualizaciones y eliminaciones en 200 tablas para analítica, por lo que el CDC genérico a nivel de fila sigue siendo necesario. Ambos patrones pueden coexistir para diferentes consumidores.