Contratos de datos: por qué validar el esquema no basta

El despliegue termina sin errores. Los mensajes siguen llegando, el campo sigue siendo numérico y ningún consumidor se queja. A la mañana siguiente, el informe muestra importes cien veces mayores. El sistema funciona con una disciplina admirable. Está interpretando céntimos como si fueran euros.

Es un escenario hipotético. Supongamos que un productor cambia la unidad de un importe y conserva el nombre del campo y su tipo entero. El valor que antes era 25 ahora es 2.500. Para una comprobación limitada a la estructura, ambas versiones pueden ser perfectamente legibles. Para quien calcula un total, la diferencia es bastante menos discreta.

El problema de fondo es que un dato puede seguir siendo compatible con el esquema y dejar de ser compatible con su uso. Si la aprobación de un cambio solo pregunta si el mensaje se puede leer, parte del contrato queda fuera de la conversación.

Qué garantiza la compatibilidad de esquemas

La compatibilidad de esquemas establece qué versiones pueden leer datos producidos con otras versiones, según el formato y las reglas configuradas. No garantiza por sí sola que una unidad, una definición de negocio o el significado de una ausencia permanezcan iguales.

La documentación de Schema Registry de Confluent distingue compatibilidad hacia atrás, hacia delante y completa. La dirección importa: que un consumidor nuevo pueda leer datos anteriores no implica que uno antiguo pueda entender datos nuevos. Las reglas concretas también dependen del formato de serialización.

Hay además una diferencia temporal. La comprobación BACKWARD predeterminada no es transitiva: contrasta con la última versión. BACKWARD_TRANSITIVE amplía la comprobación a las versiones anteriores. Es una capacidad documentada de ese producto, no una descripción de cómo está configurada cualquier plataforma que encontremos.

Estas garantías son valiosas. Evitan roturas estructurales y ayudan a coordinar la evolución. Pedirles que descubran por sí solas un cambio de euros a céntimos equivale a encargarle al lector de un documento que adivine una decisión de negocio que nadie le ha comunicado.

El contrato vive también en lo que se da por supuesto

Una unidad es un caso fácil de visualizar. Hay otros cambios menos ruidosos. Un estado llamado «activo» puede pasar de significar que el cliente tiene un contrato vigente a significar que ha iniciado sesión en los últimos treinta días. Un campo vacío puede dejar de representar «desconocido» y empezar a significar «no aplica». El nombre, el tipo y hasta los valores permitidos pueden mantenerse.

Son ejemplos inventados para distinguir dos problemas. La compatibilidad estructural permite interpretar la forma del mensaje. La compatibilidad de significado permite seguir tomando la misma decisión con él. La segunda necesita conocer las expectativas del consumidor, no solo inspeccionar el contenedor.

Confluent lo recoge al definir el contrato de datos como un acuerdo sobre estructura y semántica. Su documentación incluye aspectos como metadatos, reglas de calidad y evolución. Que una herramienta permita expresar reglas no significa que conozca las que hemos omitido. Alguien sigue teniendo que identificar la expectativa y convertirla en un acuerdo verificable.

Esto conecta con el contrato de significado de una métrica, pero el problema aquí aparece antes del dashboard: en la frontera donde un sistema entrega información a otro. Una definición clara del informe no impide que el productor cambie silenciosamente la materia prima.

El consumidor olvidado suele estar en el histórico

Podemos avisar a los equipos activos y aun así dejar una trampa preparada. Imaginemos un consumidor que reconstruye el último año de actividad después de una incidencia. En ese período conviven registros con la unidad antigua y con la nueva. Si no existe una señal fiable para distinguirlos, el mismo campo representa cantidades incompatibles dentro de una lectura aparentemente homogénea.

La fecha de recepción tampoco resuelve siempre el problema: un mensaje antiguo puede llegar tarde o volver a procesarse. Lo que necesitamos es una relación demostrable entre el dato y la definición que le corresponde. Según el sistema, puede apoyarse en una versión explícita, un campo nuevo o una frontera temporal cuya validez esté realmente garantizada. Elegirla exige entender cómo circulan y se conservan los datos.

Por eso, «todos los consumidores actuales están actualizados» no responde a «podemos reconstruir el pasado». Y una garantía estructural transitiva tampoco recupera una unidad que nunca se registró. La historia necesita significado, además de bytes legibles.

Pasaporte del cambio de datos

El pasaporte del cambio de datos es una propuesta propia para hacer visible lo que debe acompañar a una modificación. No pretende crear un comité para cada campo. Se puede resumir en una ficha breve que permita a un consumidor decidir si continúa, se adapta o necesita detener el uso.

Antes y después

Qué representaba el dato y qué representará, incluidas unidad, población y significado de valores ausentes.

Lectores afectados

Quién consume ahora, quién procesa con retraso y quién puede volver a leer el histórico.

Frontera entre versiones

Cómo reconocer de forma fiable qué definición corresponde a cada registro.

Evidencia de continuidad

Qué comportamiento del consumidor se ha comprobado y qué casos siguen fuera de la verificación.

Salida del cambio

Quién puede frenar la transición y qué significa volver atrás cuando ya existen datos con la nueva definición.

En el ejemplo de los importes, el pasaporte dejaría escrito que cambia la unidad, que los cálculos de totales son consumidores afectados y que el reprocesamiento necesita distinguir ambas representaciones. Una comprobación con un importe conocido tendría que conservar el mismo valor económico después de interpretarlo. Que el campo acepte 2.500 no sería evidencia suficiente.

La ficha tiene un límite importante: depende de conocer los consumidores y sus usos. Si hay exportaciones o procesos fuera del inventario, no puede garantizar continuidad para ellos. Esa incertidumbre debe quedar visible. Declarar «sin impacto» porque nadie respondió a un aviso es convertir falta de información en una garantía.

Frenar un cambio también requiere una definición

Volver a la versión anterior del productor no elimina los datos emitidos durante la transición. En nuestro ejemplo, dejaríamos una franja de importes en céntimos entre registros expresados en euros. El código volvería atrás y el problema permanecería en el histórico.

Esta es la razón para discutir la salida antes de dar por cerrado el cambio. Podemos necesitar conservar ambas representaciones, corregir el tramo afectado o impedir temporalmente un consumo. Son decisiones de diseño que dependen del sistema; ninguna se deduce del mensaje verde de un despliegue.

El objetivo es bastante concreto: que quien recibe un dato no tenga que descubrir una decisión ajena a través de un resultado absurdo. El esquema protege una parte de la relación. El resto necesita acuerdos que sobrevivan a los cambios, al retraso y a la memoria del equipo.