Who this is for. Anyone designing a job that touches more than a handful of records. Afterwards you can put the volume where it belongs and keep event jobs quick.
The difference
| Event job | Scheduled job | |
|---|---|---|
| Started by | One record changing, or one request | The clock |
| Works on | That record: a few actions | Many records, selected each run, in a loop |
| Should finish | In seconds; a synchronous one while its caller waits | Well inside its interval, and far inside the eight hours a loop may wait |
| After a failure | Re-run that run | The next run takes what is left: it selects work by "not yet done" (a missing external id, a status, a watermark), never by position |
The symptom of the wrong choice
A job that works in testing and times out, or never finishes, under real data. The usual shapes:
- an entity event job that retrieves and loops over every product each time one product is saved, so a bulk edit of 500 products starts 500 runs of 500 elements each;
- a synchronous web event that does a nightly export's work while its caller waits, until the caller's own timeout ends the conversation;
- a schedule that tries to handle the whole backlog in one run and meets the loop's eight-hour limit.
The fix is the same each time: let the event job do only what its one record needs, and move the volume to a schedule that takes a chunk per run and remembers where it got to (Watermarks and chunking). If something must happen soon after an event but involves volume, the event job can record that work is due, a flag or a site data entry, and the next scheduled run does it.