Make my background workers deploy-safe. Right now I have workers processing jobs from a queue, but I've never checked what happens to in-flight jobs when I redeploy or when the worker crashes. Do each of these: 1. Separate the deploy: workers should be a distinct process type from the web app so I can restart or scale them independently. Don't run workers inside the web process; a slow job will block requests. 2. Graceful shutdown: on SIGTERM, the worker should stop pulling new jobs, finish the ones in flight (up to a timeout), and only then exit. If a job is still running past the timeout, the queue library should either extend the visibility timeout or requeue the job on the next worker. 3. Idempotency: every job should be safe to run twice. Redelivery happens (a worker dies mid-job, a network hiccup ACKs late). Store an idempotency key or check 'is this already done' at the start of the handler so the second run doesn't double-charge, double-send, or corrupt state. 4. Retry policy: bounded retries with exponential backoff and jitter. Permanent failures go to a dead-letter queue I actually check. Do not retry forever; that's how one poisoned job burns a worker for a week. 5. Monitoring: queue depth per queue, jobs processed per minute, failure rate, and age of the oldest job. Alert on 'oldest job older than N minutes' rather than just queue depth; deep queues that drain quickly aren't a problem, but old jobs are. 6. Concurrency limits: cap workers per queue so a spike doesn't hammer the database or a third-party API. Different queues can have different concurrency. Don't skip idempotency 'because retries are rare'; they aren't. The deliverable is workers running as their own process, graceful-shutdown handlers implemented, idempotency guards on the critical handlers (payments, emails, external calls), retries bounded with a dead-letter queue in place, and monitoring wired up.