Skip to content

Infrastructure & Integrations

Queues and background jobs: answer now, do the slow work where you can see it

A customer taps Book and waits while the app sends a text, resizes photos and updates accounting. If accounting is down, the booking fails, or half-happens. Work that's slow or depends on someone else's system belongs in a queue: the customer gets an answer at once, and each job is retried safely, never done twice, and handed to a person when it can't finish.
Talk through your slow workSee what goes in a queue ↓
R-102 booked · D.P. sees “booked” in 0.3 s4 jobs queuedwaiting432211101100running012121121110done000112222223needs a person000000000011text · R-102 confirmationqueuedtext · R-102 confirmationsendingtext · R-102 confirmationsent · 1 attemptthumbnails · J-644queuedthumbnails · J-644making 2 sizesthumbnails · J-644done · 1 attemptINV-2301 → accountingqueuedINV-2301 → accountingsendingINV-2301 → accountingaccounting unavailableINV-2301 → accountingretry in 1 minINV-2301 → accountingsending · attempt 2INV-2301 → accountingsent · 2 attemptstext · C-0412 reminderqueuedtext · C-0412 remindersendingtext · C-0412 remindernumber not in servicetext · C-0412 reminderoffice to call C-0412

What goes in a queue

If the person doesn't need to see it finish, it probably doesn't belong in the request.
Confirmation texts and emailsthe texting service can be slowretried; after the last try, the office sees it
Photo sizestakes seconds per photoretried; the original is always kept
Invoices to accountingaccounting can be unavailableretried for hours, then shown to the office
Monthly plan renewalshundreds at onceeach renewal on its own; one failure doesn't stop the rest
Reportsminutes of workretried; whoever asked gets told when it's ready, or that it failed

Rules every job follows

A queue only helps if every job on it behaves. These are written into each one.

  1. 01

    Safe to run twice

    Same job, same result

    A job can be picked up twice after a crash. The invoice is still created once and the text still sent once.

  2. 02

    Retries that wait longer each time

    A minute, five, half an hour

    So a struggling service gets room to recover instead of being hit harder.

  3. 03

    A time limit

    Stuck isn't the same as slow

    A job that runs past its limit is stopped and retried, not left running forever.

  4. 04

    Visible

    Waiting, running, done, failed

    Anyone responsible can see what's queued, how long it's waited and what failed, without asking a developer.

  5. 05

    A place for what can't finish

    With the reason, for a person

    After the last retry, the job goes to a list someone checks, with what it tried and why it stopped.

Three ways a job fails

Each needs a different answer, decided before it happens.

INV-2301 → accounting

  1. Attempt 1

    accounting unavailable

    failed

  2. Wait 1 minute

    done

  3. Attempt 2

    invoice created in accounting

    done

Nobody had to notice. The job log shows both attempts.

Where the queue sits

In

Requests
work that can wait
Schedules
renewals, reports
Events
from other systems
Queue and workers
retry, time limit, once only

Out

Connected systems
texts, accounting
Needs a person
with the reason
Job log
every attempt

Worth adding when people wait on work they don't need to see

Good fit

  • Screens hang while something is sent or processed.
  • Your software depends on services that are sometimes down.
  • Failed sends and syncs are found by customers, not staff.

Not the right fit

  • Everything finishes quickly and nothing depends on another service. A queue adds parts to run for no gain.
  • The work is a business process people follow. That's workflow automation.

Where this capability is used

Next to queues

Questions about queues and background jobs

Does every app need a queue?

No. If everything finishes quickly and nothing depends on another service, ordinary code is simpler and safer. A queue earns its place when work is slow, unreliable or happens in large batches.

What stops a job running twice?

Each job carries a key, and the step that matters checks it first: if this invoice or this charge already exists, it isn't created again.

Who sees failed jobs?

Whoever you choose. Usually the office sees the ones they can fix, like a wrong phone number, and the developer sees the rest.

How is this different from workflow automation?

Workflow automation runs your business processes, often with people in the steps. Background jobs are the software's own housekeeping: sending, resizing, syncing. Many systems use both.