How to get background jobs right
It comes up on almost every project, usually later than it should. The short answer to background jobs is that it is mostly a sequence of small decisions, not one big one.
Most development decisions are really maintenance decisions wearing a different hat. If two people in the business would answer this differently, that gap is the actual problem.
What is actually at stake
Anything slow should happen outside the request cycle. Getting it slightly wrong is survivable. Ignoring it entirely is not. It rarely shows up as a line item, which is exactly why it slips.
The steps
- Establish what you have today before changing anything
- Jobs need retries, because networks fail
- Monitor the queue depth or failures pile up unnoticed
- Write down the decision so the next person does not re-litigate it
Monitor the queue depth or failures pile up unnoticed. This is the sort of thing that compounds, quietly, in both directions. The version that survives contact with a real deadline is the simple one.
Where to go from here
In practice
The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about background jobs before you move on:
- Someone can say what the current setup is without going to look
- Jobs need retries, because networks fail — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If any of that sounds like a description of your current setup, it is fixable.