Seis reglas para una sincronización que funciona mientras nadie mira

El 8 de octubre de 2026, Lance Martin y CJ Avilla publicaron un recorrido por un agente que lee Slack y GitHub cada mañana y publica un resumen en Slack. Nadie lo mira mientras funciona. Su párrafo más útil trata de un fallo que parece un éxito. Cuando el servidor de una fuente está caído o su token ha caducado, «el agente no ve nada de esa fuente e informa de que “no hay nada nuevo”».

Una sincronización de contactos de Shopify a Brevo tiene el mismo fallo. Igual que cualquier sincronización programada entre dos herramientas SaaS. Una lectura que falla en silencio se parece exactamente a una tienda en la que hoy no se ha registrado nadie.

Su artículo termina con seis reglas para un agente que funciona sin supervisión. Léelas como alguien que gestiona sincronizaciones y cada una es una regla de reverse ETL. El worker murió. La sincronización, no. sigue a un contacto a través de una caída. Esta página es la lista de comprobación que está por encima: seis reglas para una sincronización de datos automatizada, lo que hace hoy el runner de Tajo con cada una y dónde se queda corto. La parte del runner está explicada en Recuperar una sincronización atascada o fallida.

1. Lee desde un marcador y muévelo solo cuando el lote haya llegado

Su primera regla: «Lee cada fuente desde un marcador, no desde una ventana de tiempo fija». Una ventana de «las últimas 24 horas» deja un hueco cuando una ejecución empieza tarde y repite registros cuando empieza pronto.

Una sincronización de Tajo lee su fuente por lotes desde un cursor guardado. El cursor avanza al final de un lote, y solo cuando todos los registros de ese lote han llegado. Una ejecución que falla conserva la última posición limpia, de modo que la siguiente vuelve a leer el lote interrumpido en lugar de saltárselo.

Los pedidos tienen un marcador propio. Una sincronización programada de pedidos de Shopify empieza en su primera ejecución programada y envía lo que ha cambiado desde la anterior. Los pedidos pasados solo se envían cuando una persona ejecuta la sincronización. Las ejecuciones programadas y las que inicia una persona tienen cursores separados, así que una carga del historial o un lote de prueba no pueden hacer retroceder el programado.

El coste es que un lote interrumpido se lee dos veces. La regla 2 es la que lo hace seguro.

2. Da a cada escritura una clave que sobreviva a la caída

Su cuarta regla solo da un mensaje por enviado «cuando Slack lo confirma», y solo entonces actualiza el marcador y el registro. Una carta certificada funciona así. Está entregada cuando vuelve el acuse de recibo firmado, no cuando sale de la ventanilla.

Antes de que Tajo escriba un registro, el registro recibe una clave de entrega. La clave es un hash de la sincronización, la fuente, el cursor de página, la posición en la página y el propio registro, así que no contiene datos personales. Se reserva antes de llamar al destino y se marca como completada cuando la escritura tiene éxito. Las claves completadas se conservan siete días. Un reintento, o una ejecución programada posterior, calcula la misma clave para el mismo registro, la encuentra completada y no vuelve a llamar al destino.

Esto tiene dos costes. Pasados siete días, el registro olvida, y una repetición desde un cursor más antiguo puede volver a escribir. Y una escritura que agota el tiempo de espera deja una duda honesta: puede que el otro sistema la guardara sin responder. Tajo vuelve a intentar esa escritura en un intento posterior en lugar de registrarla como fallida durante siete días. Un conector que entrega al destino una clave de idempotencia propia cierra esa duda. Uno que no puede se queda con la posibilidad de un duplicado.

3. Una sola ejecución es dueña de la sincronización y lo demuestra antes de cada escritura

Su tercera regla: «Vuelve a comprobar cada elemento justo antes de publicarlo». En una sincronización, lo que más probablemente ha cambiado entre la lectura y la escritura es quién tiene permiso para escribir.

Cada sincronización de Tajo tiene un lease, con su propio token y una vida de 15 minutos que se renueva cada cinco minutos. Una ejecución comprueba que sigue teniendo el lease antes de llamar al destino, y otra vez antes de mover el cursor. Una ejecución que lo ha perdido se detiene, y su página dice «La ejecución perdió su turno a mitad de camino y se detuvo para no escribir dos veces». Una segunda ejecución que choca con otra en curso termina en lugar de ponerse en cola detrás.

También se comprueban los registros. Entre la lectura y la escritura, los registros pasan por el filtro de consentimiento. Un contacto que se escribiría en una audiencia de marketing sin consentimiento demostrable se rechaza en lugar de suponerse. En palabras de la página de ayuda, el modo de fallo es «demasiado prudente», nunca «enviado de más».

4. Reintenta lo pasajero, detén lo persistente

Sus seis reglas no dicen nada sobre cuántas veces volver a intentarlo. Una sincronización necesita esa regla, porque sus fallos más comunes son un límite de frecuencia y un mal minuto de un proveedor.

Una ejecución de Tajo en cola que falla recibe cinco intentos. Las esperas entre ellos son de 60, 120, 240 y 480 segundos, unos quince minutos en total. Algunos fallos nunca se reintentan, porque volver a intentarlo no puede arreglarlos. Una ejecución que chocó con otra ya en curso no se reintenta, y tampoco una cuya versión publicada o cuyas conexiones ya no son válidas.

Una racha no es un tropiezo. Si las cinco últimas ejecuciones terminadas desde el último cambio de la sincronización han fallado todas, Tajo pausa la sincronización y muestra el último error en su página. Un solo éxito pone el contador a cero. Nada reanuda por sí solo una sincronización pausada; una persona corrige la causa y la vuelve a publicar. El artículo del worker que murió cuenta el incidente que dio lugar a esta regla.

5. Trata el silencio como un hallazgo

«Informa de una lectura fallida como ilegible, nunca como un día tranquilo». Es la más difícil de las seis, y la que solo cumplimos en parte.

Donde se cumple: una lectura con error hace fallar la ejecución. Un token rechazado o un servidor que no responde no envía nada al destino, deja el cursor donde estaba y cuenta para la pausa tras cinco ejecuciones fallidas. Y cada hora, a los 13 minutos, Tajo revisa cada espacio de trabajo con una sincronización activa. Alerta a su propio equipo cuando no ha habido ninguna ejecución correcta en las últimas 24 horas, incluido un espacio de trabajo donde no se ha registrado ninguna ejecución. Esa es la comprobación horaria.

Donde no se cumple: la lectura silenciosa que describen los autores es una lectura que responde «OK» sin registros. Nuestro runner la cuenta como un éxito. Para fuentes como los clientes de Shopify, una comprobación aparte avisa al equipo de Tajo tras diez ejecuciones correctas seguidas con cero registros, si la sincronización había producido registros antes. Los pedidos de Shopify se leen por fecha de actualización, así que allí una ejecución vacía es normal y esa comprobación no se ejecuta. Una fuente que devuelve algunos registros, pero menos de los que debería, no se detecta en absoluto.

La objeción dice así: «Diez ejecuciones vacías son dos horas y media con un calendario de 15 minutos. ¿Por qué no alertar en la primera?». Las sincronizaciones de contactos se ejecutan cada 15 minutos por defecto. Y una tienda sin clientes nuevos en un cuarto de hora es algo corriente. Una alerta en la primera ejecución vacía saltaría cada noche, y una alerta que siempre salta es una que nadie lee. Ese umbral cambia velocidad por credibilidad. Sigue siendo una suposición sobre el silencio, no la regla de los autores.

6. Decide una vez lo que la sincronización puede escribir y haz que cada ejecución lo demuestre

Su quinta regla guarda las preferencias del agente «en un almacén que el agente no puede editar». La sexta da al agente acceso de solo lectura allí donde solo lee y limita lo que cada ejecución puede gastar. Ambas existen porque el agente lee texto escrito por otras personas, y ese texto puede intentar darle órdenes.

La versión del archivo de preferencias en una sincronización es la regla publicada. Publicar una sincronización de Tajo la vincula a un resumen criptográfico de la regla exacta que se previsualizó. Editarla la devuelve a borrador, y vuelve a pasar por la vista previa antes de ejecutarse de nuevo. Cada ejecución comprueba, antes de cambiar nada, que está ejecutando esa versión publicada con las conexiones con las que se publicó. Una ejecución que no supera esa comprobación no se reintenta. La dirección también está fijada: una regla de sincronización escribe en un solo sentido y nunca de vuelta en Shopify.

El límite de gasto no tiene equivalente. Nuestras ejecuciones de sincronización no tienen límite de gasto por ejecución. El límite de reintentos y la pausa acotan cuánto puede durar un fallo, no lo que cuesta una ejecución.

Qué está construido y qué no

Construido, en el momento de escribir esto:

• Un cursor que solo avanza tras un lote en el que han llegado todos los registros, y un cursor de pedidos programado que las ejecuciones iniciadas por una persona no pueden hacer retroceder.
• Una clave de entrega por registro, comprobada contra un registro de escrituras completadas que se conserva siete días.
• Un lease por sincronización, comprobado antes de la escritura y antes de que avance el cursor.
• Cinco intentos por ejecución, con una espera de 60 segundos y luego de 120, 240 y 480, sin reintento ante una colisión o una publicación no válida.
• Una pausa cuando fallan cinco ejecuciones seguidas, visible en la página de la sincronización.
• Una alerta horaria cuando ninguna ejecución ha tenido éxito en las últimas 24 horas.
• Un filtro de consentimiento en tiempo de ejecución para los contactos que se escriben en una audiencia de marketing, y una comprobación en cada ejecución de que es la versión publicada.

No construido, y conviene saberlo antes de confiar en ello:

• Una lectura que tiene éxito con cero registros no se notifica como ilegible. El aviso tras diez ejecuciones cubre una parte. No cubre los pedidos de Shopify ni una fuente que devuelve menos registros de la cuenta.
• La alerta de 24 horas llega a Tajo, no a ti, y lo mismo ocurre con el aviso tras diez ejecuciones. La pausa sí aparece en la página de la sincronización.
• La comprobación horaria vigila el espacio de trabajo, no cada sincronización. Una sincronización sana oculta una silenciosa a su lado.
• No hay límite de gasto por ejecución.
• Nada reanuda una sincronización pausada. Lo hace una persona.
• La pausa tras cinco fallos y la comprobación de 24 horas se configuran para todo el despliegue de Tajo, no por sincronización.

Cuando uno de estos casos aparezca en tu propia sincronización, Recuperar una sincronización atascada o fallida explica qué ves y qué hacer.

Los autores escribieron seis reglas para un resumen que una persona lee cada mañana. Una sincronización no tiene ningún lector por la mañana, y por eso las necesita todavía más. Las reglas de la uno a la cuatro y la regla seis son código en nuestro runner hoy. La regla cinco está escrita a medias: una sincronización que no puede leer su fuente debería decirlo.