En arquitecturas desacopladas, garantizar la calidad de los datos no es responsabilidad del consumidor, sino del productor. Este enfoque cambia la forma en que diseñamos sistemas: la validación deja de ser reactiva y se vuelve estructural. En este artículo exploramos cómo implementar validación en el lado del productor usando OpenAPI y ogen, y por qué esto mejora la confiabilidad del sistema desde su base.
En sistemas modernos, especialmente aquellos construidos bajo arquitecturas desacopladas, los datos fluyen entre múltiples servicios sin una retroalimentación directa. Esto permite escalar, pero también introduce un riesgo silencioso: cuando los datos son incorrectos, el error se propaga sin control.
En Meetlabs entendemos que la calidad no puede depender de validaciones tardías ni de suposiciones implícitas. La confiabilidad del sistema empieza en el punto donde los datos nacen. Diseñar con esta premisa implica cambiar el enfoque: no se trata de manejar errores, sino de prevenirlos desde el origen.
El desacoplamiento resuelve escalabilidad y disponibilidad, pero introduce un trade-off poco evidente: la pérdida de feedback inmediato. Cuando un productor envía datos a través de colas o eventos, no existe una validación síncrona que garantice que esos datos son correctos desde el punto de vista del consumidor.
Esto convierte los errores en algo más peligroso: errores silenciosos. No fallan en el momento, pero degradan el sistema progresivamente.
Muchos equipos hablan de contratos, pero en la práctica operan con estructuras implícitas. El problema es que lo implícito no escala: cada servicio interpreta los datos a su manera.
Definir contratos con OpenAPI no es documentación, es alineación técnica. Es establecer una única fuente de verdad sobre cómo deben verse los datos.
El valor real de un contrato aparece cuando deja de ser estático. Herramientas como ogen convierten definiciones en código ejecutable, permitiendo validar requests automáticamente antes de que salgan del sistema.
Aquí es donde el diseño se conecta con la operación: lo que definiste en el schema se convierte en enforcement real.
Delegar la validación al consumidor es cómodo, pero arquitectónicamente incorrecto. Implica asumir que los errores son inevitables y que el sistema debe adaptarse a ellos.
Mover la validación al productor cambia esa lógica: ahora el sistema se diseña para evitar errores, no para reaccionar a ellos.
La validación en el productor no reemplaza un buen modelado de datos. Si el diseño es débil, validar solo asegura que el error es consistente, no que el sistema es correcto.
Por eso, la validación debe entenderse como una extensión del diseño, no como un parche.
En sistemas desacoplados, la calidad de los datos no puede depender de validaciones tardías. Diseñar validación en el productor transforma la confiabilidad del sistema, evitando errores antes de que existan y reduciendo la complejidad en toda la arquitectura.
