Operating a document AI pipeline requires control over every layer of processing demand. This education data engagement shows how Horus Technology improved an IDP baseline through infrastructure as code, queueing, failure handling, and concurrency engineering.
The customer and operational challenge
An education data company uses course catalogs to provide standardized course and program information to universities and education technology platforms. Its document-processing baseline combined Amazon S3, AWS Lambda, AWS Step Functions, model inference, and database persistence.
Catalogs varied in size and format. A single document could create multiple batches, and each batch could create multiple chunks. Increasing parallelism at one level could overload a downstream model API or create more simultaneous Lambda demand than the processing configuration could support. Large intermediate results also had to fit within workflow payload constraints.
The DevOps challenge was to make processing demand predictable, failures recoverable, and capacity settings reviewable as the workload evolved.
Infrastructure and workflow changes
Horus Technology maintained the processing infrastructure in AWS CDK, with version-controlled definitions for compute, state machines, storage access, and workflow admission. The pipeline used S3 for source documents and intermediate artifacts, Lambda for processing stages, Step Functions for orchestration, and DynamoDB and RDS for processing data and structured outputs.
- Distributed processing: In July 2024, we introduced separate batch and chunk Distributed Map workflows, with dedicated aggregation and result-joining stages.
- Queued admission: We added an SQS-backed workflow-start throttle to control the incoming processing demand independently of the work inside each document.
- Failure handling: We added retry backoff, an error catcher, and a separate text-extraction workflow. We also investigated memory pressure in chunk creation.
- Capacity controls in code: Batch, chunk, and document concurrency settings could be reviewed and changed through source control rather than left as undocumented console settings.
Concurrency tuning: exact changes
The operating configuration changed as we learned where the bottlenecks were. In August 2024, we reduced batch concurrency from five to three and chunk concurrency from five to two to protect downstream model capacity. We also increased retry backoff.
A subsequent investigation recorded chunk-processing invocations capped at two, with approximately 23-25 seconds per invocation and no Lambda throttles in the report's observation window. This identified the configured orchestration cap as a throughput constraint during that window.
In July 2025, we committed a revision to those capacity controls:
| Control | Before | After |
|---|---|---|
| Chunk Map concurrency | 2 | 15 |
| Batch Map concurrency | 3 | 15 |
| Document admission threshold | 10 | 75 |
| SQS batch size | 1 | 5 |
| Artificial delay in chunk Lambda | 1-30 seconds | Removed |
These values are application settings, not AWS service quotas. The changes establish what was implemented. The optimization commit forecast a 7.5x-11x throughput improvement; that forecast is not presented here as a measured production result.
Operational outcomes
The delivered platform had explicit controls for admitting work, distributing batches and chunks, handling failures, and adjusting processing capacity. Its source history records both conservative settings used to protect model capacity and a later revision addressing underutilized processing capacity.
This work established an iterative operating process: investigate observed behavior, identify the constraining layer, change infrastructure and application settings in source control, and reassess downstream demand. A higher Map concurrency setting alone does not establish a proportional improvement in completed documents per hour.
The architectural lesson applied later at VRC
Our subsequent VRC engagement encountered a related orchestration problem. Nested document, patient, and chunk processing multiplied Lambda demand. The January 2026 investigation identified duplicate SQS event-source mappings and demand exceeding a processing function's reserved concurrency.
One VRC remediation explicitly budgeted three document launches, five patient iterations, and three chunk iterations: 45 potential simultaneous calls against reserved concurrency of 50. This made the relationship between queue admission and internal fan-out explicit.
In April 2026, we implemented ECS Fargate workers for VRC that consume SQS messages and run document-processing stages in-process. The worker path removed the per-stage Lambda invocation fan-out and introduced queue-based worker scaling, graceful shutdown, and deployment controls. Inference hosting on ECS was a separate architectural change.
VRC's development validation report records a 1,000-document stress test completed in 556 minutes with zero dead-letter queue messages. Workers scaled from two to ten. GPU capacity was increased manually, and a later GPU autoscaling interruption required manual restoration while workers retried and resumed. These are VRC test results with operational qualifications; the education data customer's documented changes are the queueing, workflow, and capacity improvements described above.
DevOps for document-processing platforms
Horus Technology helps teams operate and improve document AI workloads on AWS through infrastructure as code, concurrency and capacity planning, queue-based admission, retry and recovery design, and validation of architectural changes. We evaluate the full processing path, including model APIs, GPU capacity, storage, and databases, when choosing between serverless orchestration and container workers.
For the scope of this work, see our DevOps services for document processing.