Background Jobs That Remember Whose Work They Are Doing

Some work is too slow to do while a visitor waits. Sending a newsletter to thousands of members, generating image sizes after an upload, building an export, checking an import: all of these happen in the background. The visitor's request finishes quickly, and a queue of jobs does the heavy lifting a moment later.

In a platform that serves many customers, that moment later is where a subtle danger lives. By the time a job runs, the request that created it is gone, along with the information about which customer it belonged to.

The forgotten context problem

During a web request, our platform knows which account and which website the visitor is working in. Data is filtered automatically, files go to the right place and settings come from the right customer.

A background job starts fresh. If it simply loads records and processes them, it may have no account active at all. Depending on how the code is written, that can mean it sees too much data, writes files to the wrong place or reads settings from the wrong customer.

Our rule: capture, then restore

Every job that works on customer data records which account and website it belongs to at the moment it is created. When the job runs, the first thing it does is restore that context. Only then does it touch any data.

This sounds mechanical, and that is the point. It is a pattern every job follows, so nobody has to rediscover it. When reviewing a new job, we look for it specifically.

Recheck permissions when the job runs

Restoring the account is not enough on its own. Permissions can change between the moment a job is queued and the moment it runs. An administrator might lose access. An account might be suspended. A feature might be turned off.

So jobs that act on someone's behalf recheck that the person and the account are still allowed to do the work before they do it. A queued export from someone who just lost access should not be delivered to them. A queued draft from a support session that has ended should not continue.

Make jobs safe to run twice

Queues retry jobs that fail. Servers restart. Occasionally a job runs twice. We design jobs so a second run does no harm: an email that was already sent is recorded and not sent again, an image size that already exists is not rebuilt, a payment-related step checks whether it already happened before acting.

When an outcome is genuinely uncertain, such as a request to an outside service that timed out without a clear answer, we do not blindly retry. We record the uncertainty and stop, so a person can confirm what actually happened. Charging someone twice is worse than waiting.

Choose what runs now and what waits

Some work can safely wait in the queue. Some should finish before a page responds. We decide case by case. For example, when we publish a large set of articles through a release, we save the articles immediately and leave the image resizing to the queue. The release finishes quickly, the articles appear right away and the extra image sizes arrive a little later.

Keep an eye on the queue

A queue that silently stops is worse than no queue, because work piles up unseen. Our platform runs a dashboard for queue workers, restarts them as part of each release and alerts our administrators when key background services stay down. You can read more about the release side in what we check after every release.

Part of a bigger habit

Background jobs are one of the places where tenant-first thinking matters most, because nobody is watching when they run. Writing them carefully is part of how we keep every organization's data where it belongs.

Frequently asked questions

What is a background job?

A background job is a task the application performs after a request has finished, such as sending email or processing files, so visitors do not have to wait.

Why do background jobs need to know the customer?

Without the customer's context, a job may read the wrong settings, see other customers' data or save files in the wrong place in a shared platform.

What happens if a job runs twice?

Our jobs are designed so a second run does no harm, and jobs with uncertain outside results stop for review rather than retrying blindly.