When background jobs is worth the effort

The advice here is unglamorous, which is probably why it gets skipped. Background jobs is not free, and pretending otherwise leads to bad decisions.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It rarely shows up as a line item, which is exactly why it slips.

When it is worth it

Anything slow should happen outside the request cycle. The cost of getting this wrong is rarely visible on the day it happens. The version that survives contact with a real deadline is the simple one.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. This is the sort of thing that compounds, quietly, in both directions.

How to decide

Monitor the queue depth or failures pile up unnoticed. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.

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
• 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.