A practical checklist for background jobs
The gap between knowing this and actually doing it is where most teams lose ground. Run through this the next time background jobs comes up.
The question is rarely whether something can be built, but what it costs to keep running afterwards. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The checklist
- Anything slow should happen outside the request cycle
- Jobs need retries, because networks fail
- Monitor the queue depth or failures pile up unnoticed
- Someone is named as the owner
- There is a date to review it again
The reason this keeps coming up
Anything slow should happen outside the request cycle. The cost of getting this wrong is rarely visible on the day it happens. It is the sort of thing that looks like polish right up until it costs you an enquiry.
How to tell if yours is fine
Most development decisions are really maintenance decisions wearing a different hat. 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 you are not sure where your systems currently stand on this, it takes us about an hour to find out.