All case studies
Just Hired AI (contract) · AI · Automation · 2026

Phantoms — AI Content Automation Engine

A queue-driven NestJS backend that takes short-form video from script to multi-platform publish — hardened with circuit breakers, retries, and dead-letter handling.

2 min read
NestJSTypeScriptPostgreSQLRedisBullMQ
Phantoms — AI Content Automation Engine
Queue-driven
Pipeline
Retry + DLQ
Resilience
AI + social
Integrations

The problem

Short-form video has a long tail of steps — generate a script, render it, get it approved, reformat and publish it across platforms, then read back the performance. Done by hand it's slow; done naively in code it's fragile, because every step depends on an external service (an LLM, a render API, a social platform) that will eventually rate-limit, time out, or fail.

The brief was a backend that runs this pipeline end-to-end and stays up when its dependencies don't.

The architecture

A NestJS service models the pipeline as a set of BullMQ queues over Redis, with PostgreSQL holding state for every asset as it moves through the stages.

Content pipeline

Failure handling is the feature

Each external call sits behind a circuit breaker — when a provider starts failing, the breaker trips and the pipeline stops hammering it instead of burning retries. Jobs that exhaust their retries land in a dead-letter queue for inspection rather than vanishing, so nothing is silently lost and a single bad asset never stalls the whole run.

Stage isolation

Every stage is its own queue with its own concurrency and rate limits. Rendering (slow, quota-limited) can't starve publishing; a spike in script generation can't overrun the render API. State in PostgreSQL means a worker can crash mid-pipeline and the asset resumes from its last completed stage.

The AI is the easy part

The model call is a few lines. The engineering is everything around it — idempotent stage transitions, breakers on every integration, and a dead-letter path that turns "it broke at 3am" into a queue you can drain in the morning.

Outcomes

Queue-driven
Stage-isolated pipeline
Per-stage concurrency and rate limits
Circuit breakers
On every integration
Stops hammering failing providers
Dead-letter
Nothing lost
Failed jobs are inspectable, not silent

What this taught me

When a backend orchestrates other people's APIs, resilience is the product. Breakers, retries, and a dead-letter queue were what made an automation people could actually leave running unattended.

Building something similar?

Send a quick note — happy to compare notes on the architecture.