How to process 3D models in bulk without crashing your backend

By Aitor Nain Mendoza Vallejo ·August 28, 2026

The challenge of geometric processing

Loading a 1 MB JSON file into your REST API's memory is trivial. Loading a 500 MB model .STEP or .glTF with millions of vertices, parsing it, validating its normals, and reducing its polygons (decimation) is a task that will bring your server to its knees.

If your system allows users to upload large 3D files and processes them on the same HTTP thread that responds to the web request, you are one step away from suffering a crash due to Thread Starvation and memory leaks (OOM - Out of Memory).

The Correct Architectural Pattern: Worker Queues

3D processing is, by nature, CPU and RAM intensive. It should never run synchronously.

The industry standard solution (used in tools like Unity Cloud Build or massive B2B viewers) is an event-driven asynchronous architecture.

1. Secure Ingestion (Zero-Trust Upload)

Do not let massive binary files cross your main REST API. Your backend should not be a file proxy.

Use Presigned URLs (or SAS Tokens in Azure Blob Storage).
The user requests permission from your API.
The API returns a temporary secure URL.
The client (browser/frontend) uploads the 500 MB file directly to Storage, completely bypassing load on your CPU.

2. Event-Driven Triggering

Once the 3D file hits storage (Azure Blob), it triggers an event (Event Grid) that queues a message on a bus (Service Bus or RabbitMQ). The message simply says: "El archivo XYZ-123.gltf está listo para ser procesado".

3. Ephemeral Scalable Workers

A pool of microservices (Workers) hosted on Azure Container Apps or Azure Batch listens to this queue. These workers are specifically programmed for heavy geometric tasks (perhaps using C++ libraries or Trimesh in Python).

The Worker takes the message and downloads the 3D file to its local storage.
Performs intensive processing (watertight validation, volume calculations, decimation).
Save the resulting processed file to another Blob.
Update the SQL database indicating that model XYZ-123 is "Ready".

Why is this superior?

Elastic Scalability: If 1,000 3D models arrive at once, your REST API still responds to web queries in 20ms. The infrastructure dynamically spins up 500 temporary containers that shut down when the queue is empty.
Resilience (Fault Tolerance): If a 3D model is corrupt and causes a crash in the processing program's memory (e.g., Segmentation Fault in C++), the container dies, but your main web application remains unaware. The message is returned to the queue or discarded (Dead-letter queue).

The Quality Barrier

Another major risk is accepting "geometric garbage." Designing this flow allows you to intercept the 3D file in the Worker and pass it through strict analysis. If you don't know how to implement this, I have detailed my solutions for these challenges in the Cloud Geometric Validation Systems and Scalable Backend for 3D Processing.

Need help designing infrastructure capable of handling massive 3D data processing? Schedule a consultation or contact us directly.