Moving work to a queue can keep a web request responsive, but it introduces asynchronous behavior and new failure modes. A queue job should have a clear purpose, bounded execution time, and a way to observe success or failure.
Assume work may run more than once
Workers can retry after a timeout or interruption. For operations that create records or trigger external effects, use an idempotency key, unique constraint, or guarded state transition so a repeat does not duplicate the outcome.
Choose retries intentionally
Retry transient failures with limits and appropriate backoff. Permanent validation or authorization failures should not loop indefinitely. Keep logs useful for diagnosis but avoid recording credentials, tokens, or unnecessary personal data.
Keep caches scoped and fresh
Define what data a cache entry represents, who may read it, and when it becomes stale. Include suitable scope in cache keys and invalidate or expire values when underlying data changes. Measure whether caching solves a real bottleneck.
Document how failed jobs are reviewed, retried, or safely abandoned. Reliable background work is as much an operational design problem as an implementation task.