Planteamiento y contexto
Esta es una pregunta de diseño de sistemas de plataformas de datos. Reverse ETL entrega modelos confiables del almacén de datos a herramientas de CRM, marketing o producto. La documentación de Hightouch describe el flujo como origen → modelo → sincronización → destino, mientras que la guía de Census enmarca la entrega del almacén a plataformas de negocio como analítica operativa. La entrevista evalúa en conjunto el procesamiento por lotes e incremental, los límites de las API de destino y la gobernanza de datos.
Qué evalúa el entrevistador
- ¿Puedes separar las instantáneas del modelo, la detección de cambios, la programación, las colas y los adaptadores de destino?
- ¿Puedes proteger un destino con claves de idempotencia y versiones cuando la entrega del origen es al menos una vez?
- ¿Puedes convertir la eliminación, la revocación del consentimiento, la deriva de esquemas y el aislamiento de inquilinos en contratos explícitos?
- ¿Puedes demostrar la confiabilidad con métricas de frescura, éxito, acumulación (backlog) y conciliación en lugar de limitarte a dibujar un diagrama de flujo de datos?
Preguntas de clarificación
- ¿El SLO de 10 minutos se aplica solo a las cohortes de alta prioridad o a cada registro?
- ¿Los destinos admiten upsert por lotes, eliminación, claves de idempotencia y cursores del lado del servidor?
- ¿El modelo expone una clave estable, hora de actualización y lápida (tombstone) de eliminación? ¿Durante cuánto tiempo se conservan las instantáneas?
- ¿Las cuotas de los inquilinos son independientes y puede un inquilino grande consumir todo el rendimiento global?
- ¿Con qué rapidez debe surtir efecto la revocación del consentimiento y deben bloquearse las nuevas sincronizaciones mientras falla la eliminación?
“Dividiría el sistema en un modelo versionado, un detector de cambios, colas por inquilino, adaptadores de destino y trabajos de conciliación. Cada registro lleva tenantid, una clave de negocio estable, versión del modelo, rowversion y estado de eliminación. Una marca de nivel alto (high-water mark) o CDC crea tareas de entrega al menos una vez. El adaptador agrupa los upserts por lotes bajo los límites del destino y utiliza el inquilino, el destino, recordid y rowversion como clave de idempotencia. Los reintentos no pueden reducir una versión; la eliminación y la revocación del consentimiento escriben una barrera ineludible. Monitorearía el retraso de frescura, el backlog, la limitación de tasa (throttling), las clases de fallas, las brechas de conciliación y la latencia de eliminación en el destino.”
Análisis detallado paso a paso
Paso 1: Definir el modelo de origen y las versiones
Trata el modelo del almacén de datos como la entrada de la sincronización; no permitas que los workers unan varias bases de datos operativas de forma ad hoc. Emite record_id, tenant_id estables, campos de negocio, row_version, updated_at, consent_state y deleted_at. Cada ejecución del modelo obtiene un model_run_id. Cuando se elimina un registro, emite una lápida (tombstone) en lugar de omitirlo silenciosamente, de modo que el worker pueda distinguir entre “no escaneado todavía” y “eliminar explícitamente aguas abajo”.
Paso 2: Detectar cambios y programar el trabajo
Prefiere una columna de actualización del modelo o una marca de nivel alto (high-water mark) de CDC. Persiste el punto de control (checkpoint) y utiliza una ventana de superposición para que marcas de tiempo idénticas no causen la pérdida de filas. Escribe un lote de cambios inmutable y luego permite que el programador lo divida por prioridad de inquilino. Calcula el retraso permitido para el SLO de 10 minutos a partir de la antigüedad de la cola; el trabajo de menor prioridad cede capacidad cuando es necesario, pero no puede eludir la cola de revocación de consentimiento.
Paso 3: Hacer que los upserts sean idempotentes
La entrega al menos una vez significa que “el worker falla después de un envío exitoso” debe ser seguro de reproducir. Cuando el destino admita idempotencia, utiliza tenant_id + destination + record_id + row_version; acepta únicamente una versión que no sea inferior a la actual. Sin idempotencia en el destino, conserva las huellas digitales (fingerprints) de las solicitudes y las respuestas, limita la concurrencia y concilia leyendo el destino. No afirmes que las transacciones entre sistemas proporcionan entrega exactamente una vez (exactly-once). Clasifica los reintentos según errores reintentables, retroceso exponencial (exponential backoff) y número máximo de intentos.
Paso 4: Aislar la limitación de tasa y la sobrecarga
Mantén un bucket de tokens o una cuota reportada por el destino por inquilino, más un límite máximo de concurrencia global. Las colas de inquilinos, la programación justa y una cola de mensajes no entregados (dead-letter queue) evitan que un inquilino grande deje sin recursos a los demás. Reintenta los errores 429, 5xx y los tiempos de espera de red con retraso; dirige los errores 4xx de esquema o autorización al manejo manual. Emite alertas a medida que el backlog se acerque al SLO y permite que los backfills de baja prioridad se pausen.
Paso 5: Gestionar la eliminación y la revocación del consentimiento
Escribe cada revocación en una barrera de eliminación independiente con el inquilino, record_id y la versión del evento. Un worker verifica la barrera inmediatamente antes de un upsert; un registro revocado solo puede enviar una eliminación hasta que la gobernanza lo autorice explícitamente. Conserva los recibos de eliminación y las marcas de tiempo del destino. La conciliación debe buscar registros prohibidos que aún existan aguas abajo; el éxito de la solicitud por sí solo es insuficiente.
Paso 6: Gestionar la deriva de esquemas y la reversión
Versiona el esquema del modelo y valida las asignaciones de campos antes del despliegue. Realiza liberaciones graduales (gray-release) de campos opcionales aditivos; bloquea los cambios de eliminación o de tipo incompatibles con un informe en lugar de romper todos los inquilinos. Mantén mapping_version en cada tarea del adaptador, reintenta los lotes fallidos con su asignación anterior y revierte a una versión validada en lugar de sobrescribir una migración parcial con el éxito más reciente.
Paso 7: Observar y conciliar
Registra source_run, el estado de la tarea, los intentos, la última versión exitosa, la latencia de la API, las limitaciones de tasa (throttles), la antigüedad de la cola y la latencia de eliminación por inquilino y destino. Las métricas principales son el p95 del retraso de frescura de alta prioridad, la tasa de éxito, los mensajes no entregados (dead letters), la tasa de errores de esquema, el delta en el recuento de origen versus destino y el delta del hash de campos muestreados. Ejecuta una conciliación completa diariamente o después de los lanzamientos, repara automáticamente las reproducciones seguras y dirige las discrepancias irreconciliables al equipo de operaciones.
Compensaciones y límites
Instantánea, incremental o CDC
Las instantáneas son sencillas pero vuelven a escanear los datos. Los incrementos basados en marcas de tiempo son más económicos, pero dependen de un reloj estable y de una columna de actualización. CDC representa las eliminaciones, pero la capa de origen o de modelado debe conservar los hechos del cambio. Explica que la elección depende de la frecuencia de actualización del modelo, la semántica de eliminación y la capacidad del destino; mantén una conciliación completa periódica como protección contra filas perdidas.
Ubicación de colas y consistencia
Las particiones por inquilino mejoran el aislamiento y el ordenamiento. Una cola global utiliza la capacidad de manera eficiente, pero necesita una programación justa. Puedes garantizar la visibilidad monotónica para la versión de un registro, pero no una confirmación atómica (atomic commit) entre el almacén de datos y el destino. Las escrituras condicionales por versión, la reproducción y la conciliación proporcionan una consistencia eventual explicable.
Backfill frente a actualizaciones en vivo
Otorga a los backfills un presupuesto independiente de baja prioridad, un cursor pausible y reconocimiento de limitaciones de tasa; envía las actualizaciones en vivo a la cola de alta prioridad. Si ambos compiten por un registro, el row_version más alto gana, y una escritura condicional en el destino debe rechazar una versión anterior.
Respuesta modelo
“Trataría el modelo del almacén de datos como un origen versionado, crearía lotes de cambios inmutables con una marca de nivel alto o CDC, y los pondría en cola por inquilino y destino. Los registros llevan claves estables, row_version, versión del modelo y versión de asignación. Los upserts utilizan la idempotencia del destino o huellas digitales de solicitud; los reintentos con retroceso exponencial no pueden sobrescribir una versión más nueva. Los buckets de tokens por inquilino y un límite máximo de concurrencia global gestionan la limitación de tasa. La eliminación y la revocación del consentimiento escriben una barrera que se verifica inmediatamente antes del envío, y se conservan los recibos de eliminación. Validaría el retraso de frescura, la antigüedad de la cola, los mensajes no entregados, los errores de esquema, la conciliación de hash de campos y los residuos de registros prohibidos. El contrato es entrega al menos una vez con consistencia eventual, no exactamente una vez entre sistemas.”
Errores comunes
- Llamar al Reverse ETL replicación de bases de datos en tiempo real mientras se ignoran la actualización del modelo y la asignación de campos.
- Decir que “la cola garantiza exactamente una vez” sin gestionar las solicitudes duplicadas hacia el destino.
- Utilizar un único límite de tasa global en lugar del aislamiento por inquilinos, lo que permite que un inquilino grande consuma toda la capacidad.
- Tratar la desaparición del modelo actual como una eliminación sin lápidas, barreras de consentimiento y conciliación aguas abajo.
- Difundir cambios de esquema sin registrar qué versión de asignación utilizó cada lote.
Preguntas de seguimiento
¿Cómo demuestras el SLO de frescura de 10 minutos?
Mide desde el momento de confirmación (commit) del modelo o el momento del evento de cambio hasta que el destino confirme la legibilidad, luego reporta el p95 y la tasa de tiempo de espera agotado (timeout) para los registros de alta prioridad. La hora de inicio del worker y los promedios son insuficientes.
¿Qué sucede si un destino solo admite reemplazar una colección completa?
Construye una instantánea versionada por inquilino con model_run_id, carga una colección temporal, valida el recuento y el hash, y cambia de versión de forma atómica. La eliminación y la revocación aún necesitan una barrera separada; no se puede asumir que la siguiente carga completa eliminará de forma segura los datos prohibidos.
¿Qué sucede si el destino tuvo éxito pero se perdió el recibo?
Reproduce la misma solicitud idempotente o concilia utilizando la huella digital de la solicitud y una lectura del destino. Si no existe ni una clave de idempotencia ni una lectura, coloca el resultado incierto en revisión manual en lugar de marcarlo como exitoso sin evidencia.
¿Cuándo debería esto convertirse en una plataforma de sincronización dedicada?
Divídelo en un servicio de tareas duradero y una capa de adaptadores cuando la cantidad de destinos, las cuotas de inquilinos, las versiones de asignación, las barreras de gobernanza y la conciliación excedan la mantenibilidad de un solo DAG. Una configuración pequeña con un solo destino puede comenzar con un orquestador y un script idempotente, pero aún necesita contratos de eliminación y reintento.