The Architecture Behind Scalable Code Conversion: From Queue to Container
When you submit a 5,000-file codebase for conversion, what actually happens? Most developers don't care about the infrastructure behind their tools — until something goes wrong. Understanding the architecture helps you make better decisions about what to convert, how to batch it, and what to expect in terms of timing and reliability.
Here's a look under the hood at how a scalable code conversion pipeline works, using real AWS service patterns.
Why Lambda Isn't Enough
The obvious first thought: throw the code at a Lambda function, have it call an LLM, return the result. For a single small file, this works fine.
For a real project, it falls apart. Lambda has a 15-minute execution timeout. A 500-file project with complex files might take 45 minutes to process. Lambda's memory caps at 10GB — fine for most individual files, but large files with extensive context require more headroom. And Lambda's cold start latency means the first invocation in a batch pays an extra penalty.
The SQS → AWS Batch Pipeline
A production-grade system uses a queue-driven architecture:
Step 1: Ingestion. The API receives the conversion request — source files, target language, configuration. It validates the input, creates a job record in DynamoDB, and drops a message onto an SQS queue.
Step 2: Orchestration. AWS Batch picks up the SQS message and spins up a container on Fargate. The container runs on ARM64 Graviton processors — roughly 20% cheaper than equivalent x86 instances for compute-heavy workloads, with comparable or better performance for most code processing tasks.
Step 3: Processing. Inside the container: parse each source file, split large files at logical boundaries (function/class definitions), batch by token budget, call the LLM for conversion, run syntax verification, execute the repair loop if needed, aggregate results.
Step 4: Delivery. Results are written to S3, the job record in DynamoDB is updated, and the user is notified. The container is destroyed. Nothing persists.
Ephemeral Containers: Security by Architecture
Every job runs in its own isolated Fargate container. When the job completes, the container is destroyed — along with every byte of source code, converted output, and intermediate state.
This isn't just good hygiene. It's a security architecture. Source code is the crown jewel of any engineering organization. A system that processes source code and retains it — in logs, in temp directories, in model training data — creates a risk surface that no security team should accept.
The ephemeral model means: no data at rest between jobs, no possibility of cross-customer data leakage, no source code used for model training, and complete isolation between concurrent jobs.
Dead-Letter Queues: Failing Gracefully
LLM calls fail. Network connections drop. Containers hit memory limits. In a system processing thousands of files, failures aren't exceptional — they're expected.
The dead-letter queue (DLQ) pattern handles this. If a job fails after the configured retry count (typically 3), the message moves to the DLQ instead of being lost. Operations teams can inspect failed jobs, diagnose the cause, and either fix the issue and replay the message or notify the user.
This is standard SQS practice, but it's worth emphasizing: a production code conversion system must handle partial failure gracefully. Converting 4,950 out of 5,000 files successfully and clearly reporting the 50 failures is infinitely better than silently dropping them.
Cost Optimization
ARM64 Graviton instances on Fargate are the sweet spot for code conversion workloads. The processing is CPU-bound (parsing, verification) and network-bound (LLM API calls), neither of which benefits from x86-specific optimizations. Graviton gives you roughly 20% cost reduction with equal or better throughput.
On-Demand vs. Spot is a genuine tradeoff. Spot instances can save 50-70%, but they can be interrupted. For interactive conversions where a user is waiting, On-Demand is safer. For batch overnight conversions, Spot with retry logic makes economic sense.
If you're interested in how B&G CodeFoundry implements this architecture, the platform runs on exactly this stack: SQS → AWS Batch on Fargate (Graviton ARM64) with ephemeral containers destroyed after every job.
References: AWS Well-Architected Framework; AWS Graviton performance benchmarks; SQS best practices documentation; NIST SP 800-190 on container security.