Reference architecture: PDF processing on Azure

Context and overview

Processing a PDF with artificial intelligence sounds simple: receive the document, extract its contents, enrich them and store the result. Complexity appears when every step introduces another service, deployment and failure point.

This reference architecture shows how to simplify that system on Azure before defining it with Terraform.

Before turning boxes and arrows into infrastructure, it is worth reviewing the diagram critically: which component solves a real need, which merely passes work along and which failure will be difficult to explain during an incident.

This architecture comes from a real Nubyron project on Azure, anonymised: we do not include the client’s name or any data that could identify it. Every environment is different, so validate security, performance, cost and regulatory requirements with your own data.

The scenario

The system must receive PDFs, react when a file arrives, analyse it with Azure AI Document Intelligence, enrich the contents with a language model, store a structured result and provide logs and traceability.

A first design variant solves the functional flow but adds several operational layers:

No individual decision was inherently wrong. The issue was the combined cost of operating all of them.

Where complexity appeared

Logic Apps acting only as an intermediary

Logic Apps is useful when orchestration contains multiple connectors and states. Here, its main job was detecting a change and invoking a Function.

Azure Event Grid can already react to Microsoft.Storage.BlobCreated. Removing the intermediary reduces configuration, cost and diagnostic paths.

Three Functions in sequence

Separating components improves a design when responsibilities and lifecycles differ. In this case, fragmentation meant deploying, observing and maintaining three pieces for one operation.

An intermediate failure stopped the pipeline and made document context harder to reconstruct.

Polling an event-based process

The scheduled trigger periodically asked whether documents were waiting. That creates delay and executions with no work.

Blob arrival is already the business event. Using it as the trigger makes the system react only when work exists.

Terraform without clear boundaries

One infrastructure block mixed compute, ingress, data and observability. Changes had a larger impact radius and parts could not be reused safely.

Proposed architecture

The simplified flow becomes:

The Function receives the event, retrieves the document, orchestrates analysis and saves the result. Application Insights centralises logs, errors and timings.

This design does not claim that a single Function is always best. It is suitable as long as processing shares the same lifecycle and fits within execution limits. If long-running jobs, independent retries or large volumes emerge, queues, Durable Functions or another orchestration pattern should be evaluated.

Isolate storage by responsibility

Storage should distinguish incoming documents, processed documents, internal Function state and structured results in Cosmos DB. Those boundaries improve permissions, retention, recovery and diagnosis.

Terraform modules

Infrastructure can be structured into modules with operational boundaries:

modules/
  ingestion/       # Storage and Event Grid
  processing/      # Function App and identity
  intelligence/    # Document Intelligence and OpenAI
  data/            # Cosmos DB
  observability/   # Application Insights and alerts

The objective is not modularising for aesthetics. Each module should represent an operational responsibility with understandable changes and permissions.

Security and operations

Before production, decide:

Event Grid may deliver an event more than once. Processing must identify completed documents and avoid duplicate results.

What to measure

An operable architecture needs a baseline:

These measures show when the solution needs queues, parallelism or additional controls.

The important decision happens before Terraform

Infrastructure as Code makes an architecture reproducible, but it can also reproduce unnecessary complexity.

Simplify the flow first. Then define ownership, failure and observability. Only then should the design become Terraform modules.

If your agency repeats this solution across clients, the next step is not copying the repository. It is creating a multi-client delivery foundation that reuses the process while keeping data and access isolated.

Is there something in your infrastructure that is not working as it should?

Tell us what is happening and we will see where to start. No sales pressure.