Cliente. Una empresa de tecnología con un producto que genera eventos de alto volumen, donde el dato no es un subproducto: es la materia prima del negocio.
Enfoque
Caso de dos eslabones del método —ingeniería de software e ingeniería de datos— en un dominio donde el volumen no perdona el descuido: a escala de streaming, un dato mal validado no se corrige a mano, se multiplica. La tesis que ordena el trabajo es directa: sin datos confiables no hay analítica ni IA que valga; solo se automatizan los errores más rápido. La validación, por eso, no es un paso final sino una propiedad del pipeline.
El problema detectado
Procesar eventos de alto volumen en tiempo real exige resolver dos tensiones a la vez: la del rendimiento —no perder eventos ni acumular lag— y la de la confianza —que lo que entra al lago de datos diga lo que dice—. En entornos así, lo que falla no suele ser el throughput, sino la calidad silenciosa: anomalías y derivas que no rompen el pipeline pero envenenan las decisiones aguas abajo.
Relevamiento funcional
El trabajo se dio en un entorno multi-stakeholder, donde distintos equipos consumían el mismo dato con expectativas distintas. Parte del relevamiento fue justamente eso: entender qué decisión sirve cada dataset, para no optimizar un pipeline contra una métrica que a nadie le importa.
Construcción de la solución técnica
- Pipelines ETL/ELT y de streaming sobre GCP (Dataflow, Pub/Sub) para datos orientados a eventos de alto volumen, diseñados para escalar sin sacrificar trazabilidad.
- Servicios backend en Python (FastAPI) y Java, desplegados vía Docker, como las piezas que rodean y alimentan los pipelines.
- Frameworks de validación de datos y detección de anomalías, integrados al flujo, para que la calidad sea una garantía del sistema y no una inspección posterior.
Capa de información y datos
Más allá del código, contribuí a estándares de gobernanza de datos en un entorno con múltiples equipos: reglas compartidas sobre qué significa un dato, cómo se valida y quién responde por él. En un producto event-driven, esa gobernanza es lo que evita que cada equipo construya su propia versión de la verdad.
Cómo se condujo el trabajo
El trabajo es anterior a las herramientas agénticas actuales: la disciplina vino del oficio, no del instrumental. El método fue el de la ingeniería de datos seria de su tiempo —validación automatizada, detección de anomalías, estándares de gobernanza acordados entre equipos—, las mismas prácticas que hoy traslado a un harness de agentes, pero entonces sostenidas a mano. Lo registro así por honestidad: no hubo IA en la construcción ni en el producto.
Qué prueba este caso
- Data engineering a escala real: streaming de alto volumen sobre GCP, no un pipeline de juguete.
- Versatilidad de stack: entrega en Python y en Java, no monocultivo.
- Gobernanza temprana: estándares de calidad y de datos en entornos multi-stakeholder, una constante de toda mi trayectoria.