VolleyAI: GPU video processing architecture

01 / The problem

VolleyAI needed to process videos asynchronously with workloads that required significant GPU memory. The architecture needed to connect video and parameter storage, processing coordination, and a containerized GPU worker without leaving expensive compute running when there were no remaining jobs.

02 / Constraints

• Input videos could be up to approximately two hours long.
• A typical processing run took approximately 30 minutes.
• The worker required approximately 10 GB of VRAM.
• GPU-capable compute should not remain provisioned when no work was waiting.

03 / Architecture

Input S3 → SQS → Controller Lambda → AWS Batch / Spot GPU worker → Output S3.

04 / Why this architecture

The design put each concern in the component suited to it: durable input and output storage in S3, pending work in SQS, orchestration in Lambda, and GPU-intensive execution in AWS Batch. Martín Rojas designed the complete architecture from the project requirements.

05 / Key decisions

• Separate storage, coordination and heavy compute.

  Why / S3 stores inputs and outputs, SQS holds pending work, Lambda orchestrates, and Batch runs the worker.

• Use SQS for asynchronous processing requests.

  Why / The queue decouples incoming work from the compute resources that execute it.

• Keep Lambda lightweight and run processing in AWS Batch.

  Why / Lambda coordinates the flow; the containerized worker handles the GPU-intensive workload.

• Align GPU compute capacity with demand and use Spot instances.

  Why / The design avoided permanently running GPU infrastructure while using Spot capacity for the expensive compute stage.

06 / Processing flow

1. 01Input videos and their processing-parameter JSON files are stored in S3.
2. 02A video upload starts the processing workflow and work waits in SQS.
3. 03A controller Lambda orchestrates the corresponding Batch processing flow.
4. 04AWS Batch runs the GPU-intensive processing worker in a container, using Spot instances.
5. 05The resulting JSON output is stored in a separate S3 location.

07 / Trade-offs

This design deliberately favors demand-aligned GPU capacity over an always-running GPU machine. The public record does not document retry behavior, Spot interruption handling, maximum concurrency, or measured infrastructure cost, so those details are not claimed here.

08 / Technical outcome

The implemented flow allowed videos and processing parameters to be stored independently from compute, requests to wait in a queue, and high-VRAM processing to run in AWS Batch before results were persisted back to S3. This case documents the architecture only; it makes no claim about commercial outcomes, quantified savings, throughput, or reliability improvements.