Decision record // Background work
A queue or a cron job?
Something needs to happen outside a request. The two obvious tools look interchangeable at small volume and stop being interchangeable at exactly the point where it matters.
The call
Cron for work the clock triggers. A queue for work a person triggers. And the moment a cron job starts scanning a table for rows marked pending, you have built a queue badly and should stop and use a real one.
When each one is right
Cron
- The trigger is time. A nightly report, a weekly digest, a cleanup sweep.
- The work is idempotent and does not mind being a few minutes late.
- Volume is predictable and finishes comfortably inside one run.
A queue
- A person starts the work. They uploaded something, they paid, they invited a colleague.
- You need retries with backoff, because the thing you are calling will fail sometimes and failing silently is not acceptable.
- Volume spikes. A thousand signups in an hour should make the queue longer, not make the system fall over.
- Order matters, or fairness between customers matters.
What it costs you later
Two failure modes, both extremely common and both invisible until they are not. The first is overlapping runs: a cron job that takes longer than its own interval starts again before the previous one has finished, and now two workers are processing the same rows. Take a lock, make the work idempotent, and preferably both. The second is the poison batch: one row throws, the entire run aborts, and the remaining nine hundred rows silently never happen. Nobody notices until a customer asks where their email went. A queue gives you per-item retries and a dead letter queue as a matter of course, and that is most of the reason queues exist at all.
Decisions like this one, on your product
This page is a general answer. Yours has constraints I don't know about. The Founding Engineer is 8 weeks with 5 founders where we make these calls on your actual codebase, and your code gets reviewed every week.
New decision records as I write them
One question, one answer, no hedging. Leave your email and I'll send the new ones. No schedule promises, unsubscribe anytime.