Background Jobs

Concept of the skill

A background job system has five primitives: a producer records durable work, a queue orders and deduplicates it, a worker leases and executes it, a state store records progress and outcomes, and a notification path tells humans or systems what changed.

Coverage

• Inline-vs-background execution decisions for web requests, API routes, workers, and serverless functions.
• Durable job contracts: job identity, payload, state, priority, ownership, attempts, progress, result, and failure record.
• Queue and worker patterns: push queues, pull queues, leases, deduplication, priority, rate control, and concurrency limits.
• Reliability patterns: idempotency keys, retry classification, exponential backoff with jitter, checkpoints, dead-letter handling, and partial failure recovery.
• User-visible progress: stage names, percentages, timestamps, cancellation, completion notification, and stale status handling.
• Verification: proving long work left the request path without losing observability or recovery paths.

Philosophy of the skill

Background jobs are not just "run this later." They are a reliability boundary between interactive work and processing work. A request handler is optimized for short, synchronous feedback. A worker is optimized for durable execution, retries, checkpoints, and controlled resource use.

The most common failure is moving code into a worker while keeping request-handler assumptions: no durable state, no idempotency, no progress, no cancellation, and no evidence of completion. That makes the system feel faster only until the first timeout, duplicate enqueue, or partial failure. A good job design makes the execution contract visible before choosing a queue product.