Scaling the 3D Neon Sign Generator: Overcoming API Gateway Timeouts
One of my core physical projects involves a custom tool that converts 2D logos into 3D-printable STLs with integrated COB LED channels to create DIY neon signs. I originally ran this script locally on my Unraid server, but I wanted to move it to the cloud to allow users to generate their own designs via a web interface.
However, migrating this heavy compute workload to a serverless AWS architecture presented an immediate, critical challenge: The 29-Second Limit.
The Architectural Problem
Generating a complex 3D mesh from a 2D image is mathematically intense. Depending on the logo's complexity, the rendering process can take anywhere from 10 seconds to 3 minutes.
AWS API Gateway has a hard, unchangeable maximum timeout of 29 seconds. If a backend integration (like a Lambda function) takes longer than 29 seconds to return a response, API Gateway drops the connection and throws an HTTP 504 Gateway Timeout error to the user.
I could have spun up a 24/7 EC2 instance to handle these requests directly, avoiding API Gateway altogether. However, applying FinOps principles, an EC2 instance sitting idle 90% of the day waiting for someone to generate a sign is a massive waste of capital. I needed a solution that scaled to zero cost when idle, but could handle long-running compute tasks when invoked.
The Solution: Asynchronous Decoupling via SQS
To solve this, I designed an asynchronous, decoupled architecture. Instead of the web frontend waiting for the 3D file to render, it simply drops a "job ticket" into a queue and immediately tells the user, "We are working on it!"
[ React Frontend ] → [ API Gateway ] → [ SQS Queue ]
↓
[ Amazon SES ] ← [ S3 Bucket (Output) ] ← [ ECS Fargate ]
1. Ingestion & Queuing
When a user submits an image, API Gateway doesn't trigger the render process. Instead, it writes a message directly to an Amazon SQS (Simple Queue Service) standard queue containing the S3 URI of the uploaded image. This operation takes less than 50 milliseconds, completely bypassing the 29-second timeout threat.
2. Containerized Compute
To process the heavy 3D rendering, I chose Amazon ECS with AWS Fargate. Fargate allows me to run Docker containers without managing the underlying servers. I configured an auto-scaling rule: when the SQS queue depth is greater than 0, Fargate spins up a container to process the message. When the queue is empty, the container spins down to zero, halting all costs.
3. Delivery
Once the Fargate task finishes rendering the STL file, it saves it to a private S3 bucket. Finally, it triggers an AWS SES (Simple Email Service) payload that emails the user a secure, 15-minute Presigned S3 URL to download their custom neon sign file.
Why This Proves Cloud Mastery
- High Availability: If my site gets featured on MakerWorld and 1,000 users request signs simultaneously, the web tier won't crash. The SQS queue simply grows, acting as a shock absorber.
- Cost Optimization: Standard SQS is incredibly cheap, and Fargate ensures I am billed per-second only when a 3D model is actively rendering.
- Security: By using Presigned URLs, the final 3D assets remain entirely private and cannot be hotlinked or stolen by bots.