Hand a slow endpoint to a real task queue

FastAPI's background tasks vanish on every redeploy. I need a job that survives one.

BeginnerRead 5 minDoing: an afternoon6 steps

What you'll have at the end

A worker running in its own process, outside your web app, that finishes a job you queued even though nothing was left running to receive it during a restart.

Before you start

You need

A FastAPI endpoint whose slow part is already a plain function you can call directly, and a broker your code can already reach.

Not covered

Choosing which broker sits behind the framework, and making the job safe to run twice once it gets redelivered.

Leans on

Move the resize job onto the framework

Point your framework at a real broker
Register the resize as a tracked job

Dispatch it from the route and watch a worker finish it

Dispatch the job and answer right away
Start a worker in its own process

Prove it survives a redeploy, then tell the app

Queue one while no worker exists yet
Report the job back by its id

Where to go next

Make a background job idempotent

go there once this job might run twice after a restart or a retry, since nothing here stops a repeat run from resizing the same photo again.

Move a slow task off the request and into a background queue

go there instead for the raw broker mechanics, with no framework wrapping the publish and consume calls for you.

Email new signups without blocking your response

reach for that instead when the job is small and truly fire-and-forget, since losing it occasionally would not matter.

Checked 19 Aug 2026

Part of the Background Job Processing Systems cookbook