Planteamiento y alcance
Aborda esto como una pregunta de diseño de ingeniería de datos. Asume 2,000 eventos de pedidos por segundo en horas pico, un objetivo de frescura de 15 minutos y un objetivo de completitud del 99.5% para los campos obligatorios. El contrato debe cubrir estructura, significado, calidad, niveles de servicio, propiedad, etiquetas de privacidad y el proceso para modificar cualquier compromiso.
El límite útil es el producto de datos entre un productor ascendente y los consumidores descendentes. La definición de una tabla de base de datos por sí sola es demasiado limitada: no puede indicar si total_amount incluye impuestos, quién es el propietario del feed o qué sucede cuando no se cumple la frescura.
Qué está evaluando el entrevistador
El entrevistador quiere escuchar un contrato que sea ejecutable, versionado y que tenga un propietario claro. Una respuesta débil enumera Avro o JSON Schema. Una respuesta sólida separa la compatibilidad de la corrección semántica, coloca las validaciones en el límite del productor y ofrece a los consumidores una vía predecible de migración e incumplimientos.
Debes conectar cada campo con una decisión del consumidor: rechazar, poner en cuarentena, transformar, alertar o continuar con un estado degradado explícito. También debes explicar cómo el contrato evita convertirse en una cola de aprobaciones no documentada.
Aclaraciones que cambian el diseño
- ¿La fuente es un flujo de eventos de solo anexado (append-only), una tabla mutable o ambos? Las instantáneas mutables necesitan claves, semántica de actualización y reglas de eliminación.
- ¿Qué garantías son barreras estrictas de lanzamiento? Un evento de pago puede rechazarse ante una moneda no válida, mientras que una etiqueta de marketing opcional puede ponerse en cuarentena.
- ¿Pueden los consumidores retrasarse una versión? Si es así, publica una ventana de compatibilidad y transformación; si no, exige una transición coordinada.
- ¿Son los eventos reproducibles y contienen datos personales? La capacidad de reproducción afecta la retención, y las etiquetas de privacidad afectan el enmascaramiento, el acceso y la gestión de eliminaciones.
Marco de respuesta de 30 segundos
“Comenzaría con los casos de uso de los consumidores y redactaría un contrato versionado y legible por máquinas. Definiría el esquema y la semántica, comprobaciones de dominio y de campos obligatorios, SLOs de frescura y completitud, propiedad, etiquetas de privacidad y una política de evolución. Los productores validan antes de publicar; el registro verifica la compatibilidad en CI; las comprobaciones en tiempo de ejecución ponen en cuarentena los registros erróneos y exponen métricas. Una nueva versión es aditiva por defecto, con una ventana de publicación dual o de transformación para cambios semánticos disruptivos. Cada incumplimiento tiene un propietario, una ruta de reproducción y un estado visible para el consumidor”.
Diseño paso a paso
1. Definir el objeto de contrato
Asigna al conjunto de datos un identificador y una versión. Para cada campo, registra el tipo, la nulabilidad, la unidad, el significado comercial, los valores permitidos, la sensibilidad y si se permiten campos desconocidos. Para el evento de pedido, indica si occurred_at es la hora del evento, si los montos son unidades menores enteras y si un pedido cancelado permanece visible.
Añade propiedad, contacto de soporte, retención, frescura, frecuencia de entrega y disponibilidad. Un nivel de servicio es medible: la frescura puede ser la antigüedad del registro aceptado más reciente, mientras que la completitud puede ser la proporción de campos obligatorios no nulos durante una ventana de tiempo.
2. Separar las comprobaciones por modo de fallo
Las comprobaciones de esquema detectan campos faltantes y tipos incompatibles. Las comprobaciones de dominio detectan un monto inferior a cero o una moneda no admitida. Las comprobaciones relacionales detectan IDs de eventos duplicados o una transición de pedido que omite un estado requerido. Las comprobaciones de frescura y volumen detectan un productor detenido o una partición parcial.
Guarda el resultado de la prueba con la versión del contrato, la compilación del productor, la partición, la ventana de muestreo y la regla fallida. Esa evidencia permite a un consumidor decidir si pausar, rellenar datos históricos (backfill) o aceptar una degradación acotada.
3. Aplicar antes y después de la publicación
En CI, compara el esquema propuesto con la versión registrada y ejecuta pruebas de contrato representativas. En tiempo de ejecución, valida en el límite del productor antes de que un evento ingrese al flujo compartido. Envía los registros no válidos a un flujo de cuarentena con la carga útil original, los fallos de reglas, la versión del contrato y una clave de reproducción.
Los consumidores aún deben validar las invariantes críticas en su propio límite. La aplicación en el productor previene muchos incidentes; las comprobaciones del consumidor protegen contra rutas mal configuradas, productores desactualizados y errores de transformación.
4. Hacer que la evolución sea explícita
Trata la adición de un campo opcional como un cambio que preserva la compatibilidad solo cuando los consumidores antiguos toleren campos desconocidos. Un cambio de nombre es disruptivo porque el significado o el nombre del campo cambian. Prefiere la estrategia de agregar y dejar obsoleto (add-and-deprecate): publica el nuevo campo, realiza escritura dual o transformación, migra a los consumidores, mide las lecturas del campo antiguo y luego retíralo tras una ventana establecida.
Para un cambio semántico como cambiar total_amount de incluir impuestos a excluir impuestos, una nueva versión y un nuevo campo son más seguros que reutilizar el nombre. Si un consumidor debe permanecer en la vista anterior, utiliza una transformación versionada y etiqueta el valor convertido.
5. Definir la gestión de incumplimientos
Utiliza niveles de severidad. Un evento de pago con formato incorrecto se rechaza y se pone en cuarentena. Un incumplimiento de frescura alerta al propietario y marca el producto de datos como desactualizado (stale). Un fallo en una descripción no crítica puede continuar registrando una métrica. El contrato debe indicar quién puede omitir una barrera, por cuánto tiempo y qué evidencia se requiere.
No descartes registros silenciosamente. Rastrea los recuentos de aceptados, rechazados, en cuarentena, reproducidos y duplicados por productor y versión del contrato. Una reproducción debe ser idempotente, por lo que el destino utiliza el ID del evento y la versión del contrato para evitar crear un segundo efecto en el negocio.
6. Verificar el modelo operativo
Ejecuta pruebas de contrato sobre datos de prueba (fixtures), pruebas de compatibilidad en cada versión propuesta y validación canario en una partición de producción muestreada. Prueba eventos tardíos, IDs duplicados, valores de enumeración desconocidos, campos obligatorios nulos, errores de zona horaria y un productor que deja de enviar.
El panel de control útil combina la tasa de incumplimiento, la antigüedad de frescura, la completitud, el retraso del consumidor, la profundidad de la cuarentena, el éxito de la reproducción y el tiempo hasta el acuse de recibo del propietario. Una comprobación de esquema en verde con un feed desactualizado sigue siendo un producto de datos fallido.
Respuesta de muestra de alta calidad
“Trataría el flujo de pedidos como un producto de datos versionado. Primero enumeraría a los consumidores y definiría la semántica del evento: hora del evento, unidades de monto, moneda, identidad y transiciones de estado. El contrato luego contendría el esquema, reglas de dominio y relacionales, SLOs de frescura y completitud, propiedad, retención y etiquetas de privacidad.
“El registro rechazaría cambios incompatibles en CI. Los productores validarían antes de publicar, mientras que un validador en tiempo de ejecución envía los registros incorrectos a cuarentena con la regla fallida y la versión del contrato. Los consumidores mantienen un pequeño conjunto de comprobaciones críticas porque el enrutamiento o la transformación aún pueden ser erróneos.
“Haría que la evolución fuera aditiva por defecto. Para un cambio de nombre o semántico, agregaría un nuevo campo o versión, publicaría de forma dual, migraría a los consumidores, mediría las lecturas del campo antiguo y retiraría la versión antigua solo después de la ventana de compatibilidad. Los incumplimientos de frescura y calidad tienen severidad, propietarios, alertas y procedimientos de reproducción explícitos. Verificaría el diseño con fixtures, canarios, eventos tardíos y duplicados, y métricas de frescura, completitud, profundidad de cuarentena y corrección de reproducciones”.
Errores comunes
- Error → Fallo → Solución: Llamar al esquema todo el contrato → los cambios semánticos y la propiedad permanecen implícitos → documentar el significado, los SLOs, los propietarios y la política de cambios.
- Error → Fallo → Solución: Rechazar cada registro no válido de forma sincrónica → un solo evento erróneo puede bloquear una partición completa → poner en cuarentena con contrapresión acotada y una clave de reproducción.
- Error → Fallo → Solución: Afirmar que los campos aditivos siempre son seguros → los consumidores estrictos pueden fallar ante campos desconocidos → verificar la compatibilidad del consumidor antes de permitir el cambio.
- Error → Fallo → Solución: Alertar solo sobre discrepancias de esquema → los datos desactualizados o incompletos aún pueden pasar las comprobaciones de esquema → monitorear la frescura, el volumen, la completitud y las invariantes de negocio.
- Error → Fallo → Solución: Reutilizar un nombre de campo después de cambiar su significado → los valores históricos y nuevos se vuelven incomparables → crear una nueva versión o un campo transformado explícitamente.
Preguntas de seguimiento y respuestas
¿Qué pasa si los productores no pueden actualizarse todos al mismo tiempo?
Mantén activo el contrato antiguo, añade el nuevo campo o versión y acepta ambos durante una ventana medida. Un adaptador de compatibilidad puede traducir la entrada antigua, pero debe exponer la pérdida de conversión y una fecha de retiro en lugar de ocultar la diferencia.
¿Qué pasa si la prueba de contrato pasa pero la métrica sigue siendo incorrecta?
Eso es una desviación semántica. Añade una invariante a nivel de negocio o una comprobación de conciliación, compara contra una fuente independiente y registra la definición en disputa en el contrato. La compatibilidad estructural no puede demostrar que un productor aplicó la regla de negocio correcta.
¿Cómo evitas que la cuarentena se convierta en un cementerio de datos?
Asigna a cada regla un propietario y un objetivo de expiración, conserva la carga útil original y la versión del contrato, y mide la antigüedad de la cola y el éxito de la reproducción. Una revisión diaria debe clasificar los fallos como errores del productor, defectos del contrato o excepciones esperadas.
¿Cuándo evitarías un data contract?
Para una tabla privada y de corta duración con un solo propietario y sin compromisos posteriores, un esquema ligero y pruebas pueden ser más económicos. Introduce el contrato completo cuando múltiples equipos, la reproducción, los campos regulados o los compromisos de frescura hagan que las suposiciones implícitas sean riesgosas.