Background jobs: the questions we get asked most

Every audit we run turns up some version of this. The questions about background jobs that come up most often on our calls.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Do we need to care about this?

Anything slow should happen outside the request cycle. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Monitor the queue depth or failures pile up unnoticed. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

The short version

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
• Monitor the queue depth or failures pile up unnoticed — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.