El punto de partida
Un cliente llegó a nosotros con una necesidad clara: automatizar el procesamiento de documentos PDF en Azure. El flujo era ambicioso — subir un documento, analizarlo con inteligencia artificial, extraer el contenido y almacenarlo de forma estructurada — pero la propuesta técnica inicial tenía margen de mejora significativo.
Antes de desplegar nada, hicimos lo que siempre hacemos: revisar el diagrama con ojos críticos.
Lo que encontramos no estaba mal en términos conceptuales. Cubría los requisitos. Pero arquitectónicamente introducía complejidad, coste y fragilidad innecesarios.
El diagnóstico: qué tenía el diseño original
El diagrama inicial planteaba la siguiente arquitectura:
- Azure Logic Apps como orquestador principal del flujo
- Tres Azure Functions en cascada: main scraper → specific scraper → data extraction
- Trigger por schedule: un temporizador lanzaba el proceso de forma periódica
- Infraestructura sin modularizar: un único bloque Terraform sin separación de responsabilidades
¿Por qué esto era un problema?
Azure Logic Apps es un servicio potente, pero en este caso actuaba únicamente como disparador y conector entre funciones. Ese rol lo puede cubrir Event Grid de forma nativa, event-driven y a una fracción del coste. Pagar por Logic Apps para hacer de intermediario es coste que no aporta valor.
Las tres Functions en cascada multiplican la latencia, los puntos de fallo y el código a mantener. Si la segunda falla, todo el pipeline se interrumpe. Si hay que hacer un cambio, hay que tocar tres piezas distintas. La lógica de negocio no justificaba esa fragmentación.
El trigger por schedule significa que el sistema se despierta cada X tiempo independientemente de si hay trabajo o no. En un flujo de procesamiento de documentos, esto no tiene sentido: el sistema debería reaccionar cuando llega un fichero, no preguntar periódicamente si ha llegado algo.
Sin modularización Terraform, la infraestructura es un bloque monolítico. Imposible reutilizar partes en otros proyectos, difícil de mantener, frágil ante cambios.
La solución: arquitectura event-driven modular
Antes de terraformar nada, propusimos un rediseño. El cliente lo aprobó. Luego sí, escribimos Terraform.
El nuevo flujo
PDF subido a Storage (incoming/)
↓
Event Grid
(Microsoft.Storage.BlobCreated)
↓
Azure Function única
↓
Document Intelligence
(análisis del documento)
↓
OpenAI
(enriquecimiento IA)
↓
Cosmos DB
(almacenamiento estructurado)Un evento real dispara un proceso real. Sin intermediarios. Sin polling.
Separación de almacenamiento por responsabilidad
Se definieron tres storage accounts con roles claros:
| Storage | Propósito |
|---|---|
ingest | Documentos entrantes (trigger del pipeline) |
func | Artefactos y estado interno de la Function |
processed | Documentos procesados (disponible para flujos adicionales) |
Esta separación permite ampliar el sistema sin modificar lo que ya funciona.
Infraestructura Terraform modularizada
La infraestructura se dividió en tres módulos independientes:
app— Azure Function, plan de consumo, application insightsweb— Capa de entrada e ingestadata— Cosmos DB, storage accounts, conexiones
Cada módulo es reutilizable de forma independiente en futuros proyectos. El coste de configurar un nuevo proyecto similar baja drásticamente.
Los resultados en producción
Una vez desplegada la infraestructura y realizadas las pruebas de integración, los logs hablaron por sí solos:
[Information] 🔥 ProcessDocumentEvent FIRED!
[Information] EventType: Microsoft.Storage.BlobCreated
[Information] Starting document processing for prueba.pdf
[Information] Processing document: prueba.pdf, size: 182492 bytes
[Information] Document Intelligence analysis complete.
[Information] OpenAI enrichment complete
[Information] Document stored in Cosmos DB
[Information] Executed 'Functions.ProcessDocumentEvent'
(Succeeded, Duration: 7136ms)El pipeline completo — desde que el PDF llega al storage hasta que los datos están en Cosmos DB — se ejecuta en 7 segundos.
Eso incluye descarga del documento, análisis con Document Intelligence, enriquecimiento con OpenAI y escritura en base de datos.
Lo que se entregó
Al final del proyecto el cliente tenía:
- ✅ Infraestructura Azure 100% terraformada y versionada en Git
- ✅ Pipeline event-driven funcional y probado en producción
- ✅ Módulos Terraform reutilizables para futuros proyectos
- ✅ Documentación técnica de la arquitectura
- ✅ Formación al equipo interno para mantenimiento y extensión del sistema
Todo en pocas semanas desde el primer diagrama hasta la entrega.
Qué aprendemos de este proyecto
El mejor momento para mejorar una arquitectura es antes de desplegarla.
Revisar un diagrama cuesta horas. Refactorizar una infraestructura en producción cuesta semanas y dinero real.
En este caso, el cambio de Logic Apps a Event Grid, la unificación del pipeline en una sola Function y la modularización de Terraform no solo simplificaron el sistema — lo hicieron más barato de operar, más fácil de mantener y preparado para escalar.
La infraestructura no es solo que funcione. Es que funcione bien, cueste lo justo y pueda crecer.
¿Tu arquitectura tiene margen de mejora?
Si tienes un diagrama que "funciona pero algo no cuadra", o una infraestructura cloud que ha crecido sin planificación, podemos ayudarte a diagnosticarla.
Este case study ha sido anonimizado. Los datos técnicos corresponden a un proyecto real.