Arquitectura de referencia: procesamiento de PDF en Azure

Context and overview

Procesar un PDF con inteligencia artificial parece un flujo sencillo: recibir el documento, extraer el contenido, enriquecerlo y guardar los datos. La complejidad aparece cuando cada paso introduce otro servicio, otro despliegue y otro punto de fallo.

Esta arquitectura de referencia muestra cómo simplificar ese sistema en Azure antes de definirlo con Terraform.

Antes de convertir bloques y flechas en infraestructura, conviene revisar el diagrama con ojos críticos: qué componente resuelve una necesidad real, cuál solo transmite trabajo y qué fallo será difícil de explicar durante una incidencia.

Esta arquitectura parte de un proyecto real de Nubyron en Azure, anonimizado: no incluimos el nombre del cliente ni datos que permitan identificarlo. Cada entorno es distinto, así que conviene validar seguridad, rendimiento, costes y requisitos regulatorios con sus propios datos.

El escenario

El sistema debe:

Una primera variante del diseño resuelve el flujo funcional, pero añade varias capas operativas:

Ninguna decisión era incorrecta de forma aislada. El problema era el coste conjunto de operar todas ellas.

Dónde estaba la complejidad

Logic Apps solo como intermediario

Logic Apps es útil cuando existe una orquestación con múltiples conectores y estados. En este caso, su trabajo principal era detectar un cambio y llamar a una Function.

Azure Event Grid ya puede reaccionar al evento Microsoft.Storage.BlobCreated. Eliminar el intermediario reduce configuración, coste y puntos de diagnóstico.

Tres Functions en cascada

Separar componentes puede mejorar una arquitectura cuando existen responsabilidades y ciclos de vida distintos. Aquí, la fragmentación obligaba a desplegar, observar y mantener tres piezas para completar una única operación.

Un fallo intermedio detenía el pipeline y hacía más difícil reconstruir el contexto del documento.

Polling para un proceso basado en eventos

El trigger programado preguntaba periódicamente si había documentos pendientes. Eso introduce espera y ejecuciones sin trabajo.

La llegada del blob ya es el evento de negocio. Utilizarlo como disparador hace que el sistema reaccione cuando existe trabajo real.

Terraform sin límites claros

Un único bloque de infraestructura mezclaba cómputo, entrada, datos y observabilidad. Los cambios tenían un radio de impacto mayor y las piezas no podían reutilizarse en otros proyectos.

Arquitectura propuesta

El flujo simplificado queda así:

La Function recibe el evento, obtiene el documento, coordina el análisis y guarda el resultado. Application Insights centraliza logs, errores y tiempos.

Este diseño no afirma que una única Function sea siempre mejor. Es adecuado mientras el procesamiento comparte el mismo ciclo de vida y cabe dentro de los límites de ejecución. Si aparecen trabajos largos, reintentos independientes o gran volumen, conviene valorar colas, Durable Functions u otro patrón de orquestación.

Aislar almacenamiento por responsabilidad

Aunque el flujo sea pequeño, el almacenamiento debería distinguir:

La separación facilita permisos, retención, recuperación y diagnóstico.

Módulos Terraform

La infraestructura puede organizarse en módulos con límites operativos:

modules/
  ingestion/       # Storage y Event Grid
  processing/      # Function App e identidad
  intelligence/    # Document Intelligence y OpenAI
  data/            # Cosmos DB
  observability/   # Application Insights y alertas

El objetivo no es modularizar por estética. Cada módulo debe representar una responsabilidad con cambios y permisos comprensibles.

Seguridad y operación

Antes de producción hay que decidir:

Event Grid puede entregar un evento más de una vez. El procesamiento debe identificar documentos ya tratados y evitar resultados duplicados.

Qué medir

Una arquitectura operable necesita un baseline:

Estas medidas permiten decidir cuándo la solución necesita colas, paralelismo o límites adicionales.

La decisión importante ocurre antes de Terraform

Infrastructure as Code hace reproducible una arquitectura, pero también puede hacer reproducible una complejidad innecesaria.

Primero se simplifica el flujo. Después se definen ownership, fallos y observabilidad. Solo entonces merece la pena convertir el diseño en módulos Terraform.

Si vuestra agencia repite este tipo de solución para varios clientes, el siguiente paso no es copiar el repositorio completo: es crear una base de entrega multi-cliente que reutilice el proceso manteniendo datos y accesos aislados.

¿Hay algo en tu infraestructura que no termina de funcionar como debería?

Cuéntanos qué está ocurriendo y vemos por dónde empezar. Sin propuestas comerciales agresivas.