Un equipo aguas arriba renombra una columna sin avisar y tu pipeline se rompe. ¿Qué haces y qué cambias después?

A corto plazo, restaura el servicio: mapea el nombre nuevo en la capa de staging, reejecuta las particiones afectadas y confirma que los números aguas abajo cuadran. A largo plazo, deja de depender de la buena voluntad. Introduce un contrato de datos con el equipo origen, valida el esquema en la ingesta para que los fallos se detecten en la frontera con un mensaje claro, y aterriza los payloads crudos sin tipar para que un renombrado no destruya la propia ruta de ingesta.

De inmediato es un arreglo pequeño: pongo un alias a la columna nueva en el modelo de staging, reejecuto las particiones afectadas y reconcilio un par de agregados de confianza para saber que nada cambió de significado además de nombre. También reviso el catálogo por si hay otros consumidores de esa tabla, porque si nos rompió a nosotros probablemente rompió a alguien más que aún no se ha dado cuenta. Luego viene la parte sistémica. Prefiero que el fallo ocurra en la ingesta con un mensaje que diga se esperaba la columna customer_id, se encontró customer_identifier, y no tres modelos más abajo con una columna nula. Así que la validación de esquema se mueve a la frontera, y la capa cruda guarda el payload tal cual, lo que significa que la ingesta sigue funcionando y solo se queja la capa tipada. Y hablaría con el equipo origen, no para quejarme sino para montar un contrato: estos son los campos de los que dependemos, estas son las alertas, avisadnos antes de publicar. Eso hicimos en mi trabajo anterior y convirtió un problema recurrente de las 6 de la mañana en un mensaje de Slack con una semana de antelación.