The queue: not doing everything at the same time

A queue is a list of tasks to do, processed in order, in the background. Instead of forcing the user to wait until heavy work is finished, the application notes the task, answers right away, and another program handles it as soon as it can.

The analogy: a restaurant kitchen

When you order, the waiter does not cook your dish in front of you while the dining room waits. They pin an order ticket on the pass. The kitchen takes them one by one. Even if twenty tables order at once, the tickets line up, and nobody blocks the service.

In an application, the dining room is what answers the user. The tickets are the tasks. The kitchen is made of dedicated programs called workers.

What it is for

You put in a queue everything that is long or not urgent for the screen:

• sending emails or notifications;
• processing an uploaded image or video;
• generating a document or an export;
• a call to an external service that may be slow;
• a heavy computation.

The user sees "in progress" in a fraction of a second, instead of staring at a spinning screen. It is one of the causes of slowness covered in why an app is slow.

What it brings

• A fast response: the user does not wait for the work to finish.
• Smoothing of peaks: if a hundred tasks arrive at once, they line up instead of crushing the server.
• Resilience to failures: if an external service is down, the task stays in the queue and is retried later.

The flip side: retries

When a task fails, it is often replayed automatically. This means the same task may be run twice. If it is an email or a charge, the outcome must stay the same: that is the principle of idempotence, which any well-designed queue relies on.

You also need to plan for:

• what happens when a task keeps failing (it is set aside and someone is notified);
• letting the user know where their work stands;
• monitoring the queue: a queue that keeps growing and never empties is a warning sign.

A queue also protects services that limit the number of calls, as seen with rate limiting.

Key takeaway

A queue lets you answer fast and do the heavy work later, one task after another. In exchange, it needs tasks that can be replayed safely, and monitoring.

And for your product?

Knowing whether what slows down or weakens your application should go through a queue shows in the code and in what it does during a request. A code audit of your app can tell. We can talk about it in a 30-minute call.