Background Jobs Finally Clicked for Me After Building This Small Demo

“Do the work asynchronously so your API stays fast.”

I understood the sentence, but it didn’t fully click until I built something small and visual.

So I picked a simple example: image processing.

At first, everything ran synchronously:

client → API → image processing → response

The API handled everything itself:

receiving the image, processing it, and returning the result.

It worked fine for small tasks.

But once processing started taking longer, the problems became obvious.

Requests slowed down.

Users had to wait.

The API started feeling heavy.

So I changed one thing:

client → API → queue → worker

Instead of processing the image directly, the API now enqueues the job.

I used LavinMQ, but the same idea works with any message broker.

Now the flow looks like this:

• You upload an image → the API stores it and sends a message to the queue → a worker picks up the job → the image gets processed in the background → a few seconds later, the results appear

In my demo, the worker generates:

• A grayscale version
• A blurred version
• A thumbnail

The interesting part wasn’t the image processing itself.

It was watching how differently the system behaved.

Before:

The client waited while the API did all the work.

After:

The API responded immediately while the worker handled the heavy processing separately.

That small architectural change finally made asynchronous systems make sense to me.

You essentially split the system into:

• A fast response layer (the API)
• A processing layer (workers)

And once you see that pattern, you start noticing it everywhere:

emails, video processing, reports, notifications, analytics pipelines — anything that takes time probably shouldn’t block your API.

Building a small demo made the idea much easier to understand than reading theory alone.