Content Carousel: engineering a durable AI workflow

Content Carousel is a Thunkle-owned product, not a client rescue engagement. It turns product research and a content plan into branded slideshows, captions and vertical video. This engineering case study describes implementation decisions in our own repository; it does not claim a measured revenue increase or a performance benchmark.

Visit Content Carousel or see Thunkle's other products. If your own AI feature needs this kind of production work, our feature-development service covers scoped implementation and handover.

The challenge extends beyond generating text

A content workflow has several different kinds of work: plan the posts, generate the material, render images, encode video and expose usable assets to the customer. Some stages take longer than an ordinary browser request.

There is also a commercial boundary. If a batch is interrupted, the product needs to know what was completed, what should be retried and what usage has been consumed. Treating all of that as a single “generate” button hides important decisions.

Durable jobs separate progress from the browser

The implementation uses persisted generation jobs and a background worker. Work can be claimed and processed independently of an open browser tab. The web app and worker have distinct responsibilities rather than asking a user to keep one long-running request alive.

The business consequence is straightforward: a customer can return to recorded progress. The engineering responsibility is less visible: job state must distinguish queued, running, completed and terminally failed work, with a recovery path for interruptions.

This architecture is not a promise that jobs never fail. It makes failure a state the application can represent and handle rather than a lost browser request.

Usage is reserved before the batch completes

The database implementation reserves generation allowance when a plan is enqueued. Completion couples creating the resulting deck and render work with consuming the reserved usage. Terminal failure paths release the relevant reservation.

That separation matters. Starting work, finishing work and charging usage are not the same event. Retries should not accidentally treat the same completion as a second purchase.

The transferable lesson for a paid AI application is to write down when an action is reserved, committed or released. A loading spinner cannot act as the source of truth for a customer's allowance.

Images and video have separate completion requirements

The render worker produces the required image outputs and queues video after the necessary images are available. The documented rendering workflow encodes video one slide at a time and bounds browser-rendering resources.

Separating the stages allows completed image assets to remain useful if video generation needs another attempt. It also gives the product a more precise status than “everything failed.”

For a different app, the same pattern might separate a generated document from its email delivery, or a successful import from an optional summary. The dependencies should follow the product's actual acceptance criteria.

Ordering needs its own regression check

A content queue should not reorder older work just because one item was recently edited. The repository includes a queue-ordering function and tests that preserve batch order and the slot within a batch; standalone drafts retain creation order.

This is a small example of a rule that a generic “page loads” test would not cover. The test expresses the behaviour the user relies on, not only the shape of the returned data.

What this demonstrates—and what it does not

The implementation shows how background work, usage accounting, partial output and interface order connect. It does not establish a universal throughput figure, prove that every path is free of defects or replace an independent security assessment.

Source review for this article focused on the worker documentation, generation-job migration and queue-ordering implementation and tests. No customer data, production credentials or private incident details are included.

Bringing the same approach to your app

A useful engagement starts with the workflow: what triggers it, what must happen once, what can retry and what the customer should see if a stage fails. From there we can scope the code, data changes and verification.

Request a feature-development quote for background jobs, AI integrations or another blocked workflow. If the app is already stuck between prototype and launch, AI-app rescue explains how we diagnose the next step.