Getting started with background jobs
The version of this that works is simpler than the version most people imagine. A short on-ramp to background jobs for teams who have not touched it before.
The question is rarely whether something can be built, but what it costs to keep running afterwards. The version that survives contact with a real deadline is the simple one.
Why this earns attention
Anything slow should happen outside the request cycle. There is a version of this that is over-engineered, and it is worth avoiding. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Your first week
- Find out what is already in place
- Jobs need retries, because networks fail
- Change one thing and measure it
Monitor the queue depth or failures pile up unnoticed. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.
How to tell if yours is fine
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about background jobs before you move on:
- Someone can say what the current setup is without going to look
- Anything slow should happen outside the request cycle — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Worth checking on your own setup before it becomes someone else's problem to fix.