Case· Imobiliária (case anonimizado)

La traba funcionó y nadie lo supo: tres días de automatización detenida en silencio

Una automatización de revalidación de base estuvo tres días detenida sin que nadie lo notara. Cada pieza de la cadena se comportó exactamente como fue diseñada, incluida la traba de seguridad que detuvo todo. El defecto no estaba en la traba: estaba en que nadie tenía el encargo de notar que se había activado.

Este case está publicado de forma anonimizada, sin nombre de cliente, sin marca y sin el nombre del sistema de terceros involucrado: el proyecto tiene contrato de confidencialidad y protección de propiedad intelectual firmado. Lo que se cuenta aquí es el modo de falla, que es el activo técnico reaprovechable.

El sistema hace revalidación de registros: recorre una base de propietarios, envía un mensaje, registra la respuesta y mantiene el registro vivo. Cruza un CRM de mercado con una lista de registros publicados, y solo habla con quien está en ambas puntas.

La cadena

En un día común el flujo es este: sincronizar la lista de publicados desde el sistema externo, armar la lista de autorizados a partir de ella, y enviar a quien está en la lista. Tres eslabones, en ese orden.

El día de la falla, el primer eslabón se rompió. La sincronización falló, la lista de publicados se congeló en la fecha anterior, y el armado de la lista de autorizados abortó en vez de seguir con la lista vieja. Los dos flujos de envío se detuvieron. Y quedaron detenidos tres días.

Todos hicieron lo correcto

La parte difícil de aceptar es que ninguno de esos comportamientos es un bug. Abortar con lista incompleta es la decisión correcta, y existe por un incidente anterior: quien no aparece en la lista de autorizados queda marcado con un estado que es terminal — no vuelve a la cola por sí solo. En una sincronización parcial, cinco propietarios legítimos quedaron marcados así y salieron de la base de envío.

Después de eso, la traba pasó a preferir detener todo antes que arriesgarse a borrar gente. Funcionó. Fue exactamente para eso que se hizo.

Desde afuera, "hoy no hubo envíos" es indistinguible de un día flojo. Fue esa ambigüedad, y no la falla, la que costó tres días.

El defecto real

El defecto no era la traba: era que nadie se enterara de que se había activado. Un sistema que falla de forma segura y silenciosa sigue siendo un sistema que falla — solo que el reloj corre a favor del problema, porque la ausencia de señal se parece a la normalidad.

Quien lo notó fue un humano, tres días después, mirando un número que no cerraba.

El modo de falla traicionero del sistema externo

La causa raíz merece registro propio, porque es el tipo de cosa que la documentación de una API no cuenta. Cuando ese sistema aplica límite de peticiones, no devuelve error de autenticación ni error de exceso de llamadas. Devuelve una lista vacía, con código de éxito.

Y la condición de fin de paginación, del lado de quien consume, es exactamente "lista vacía". Es decir: límite de peticiones y fin natural de los datos son el mismo evento para el paginador. Se detiene creyendo que terminó, y guarda una lista truncada — o ninguna — con apariencia de éxito completo.

Medido el mismo día: pedir más de veinte registros por página también devuelve lista vacía en vez de error. Quien intente acelerar la paginación por ahí va a creer que funcionó.

Lo que quedó en su lugar

Tres correcciones, ninguna en el eslabón que se rompió. Sincronización con tres intentos escalonados de madrugada, para que una falla aislada no se vuelva un día perdido. Un vigía de antigüedad de la lista dentro del auditor de producción, que grita cuando el dato envejece más de lo esperado. Y, en la aplicación manual, una traba que se niega a aplicar lista incompleta sin confirmación explícita.

Ninguna de las tres impide la falla original. Las tres garantizan que se vea el mismo día.

La lección, válida para cualquier automatización

Fallar seguro no es el final del proyecto de confiabilidad — es la mitad. La otra mitad es alguien, o algo, encargado de notar. Toda traba silenciosa necesita un vigía, y todo vigía necesita un número que envejece: no "¿dio error?", sino "¿hace cuánto que este dato no se actualiza?".

El proyecto fue entregado el 16 de agosto de 2026, con las tres frentes en el aire y en uso con dato real, dentro de la vigencia contratada, y el contrato saldado.