Hard20 minLaravel Fundamentals
UpdatedAug 5, 2026
Edit

Laravel Queues and Jobs

Question Variations

  • "Why should queue jobs be idempotent?"
  • "How do retries affect side effects?"
  • "What should run after a transaction commits?"

Why This Is Asked

Queues reveal whether a developer can move slow work off the request path while preserving correctness and operational control.

Key Concepts

  • Jobs serialize work for a queue worker.
  • Jobs must be idempotent because retries can repeat execution.
  • Timeouts, retries, backoff, and dead-letter handling need explicit policy.
  • Jobs dependent on writes should dispatch after the transaction commits.

Question Variations

  • “Why should queue jobs be idempotent?”
  • “How do retries affect side effects?”
  • “What should run after a transaction commits?”

Answers by Technology

+ Add Variant
LaravelImprove this answer ✏️

Expected Answer (Laravel 13 / PHP 8.3+)

Queue slow or retryable work so HTTP responses are not tied to email, image processing, or third-party latency. Jobs must be idempotent because workers can retry after a timeout or failure. Configure attempts, timeout, and backoff deliberately; make side effects deduplicable. Dispatch work that depends on a database change after commit.

Why It Matters

Correct job design improves request latency without duplicating payments, emails, or other side effects during retries.

Code Example

final class SendReceipt implements ShouldQueue
{
    public int $tries = 3;
    public function __construct(public int $orderId) {}
    public function handle(): void { Mail::to('customer@example.test')->send(new ReceiptMail($this->orderId)); }
}

Common Mistakes

  • Assuming a job runs exactly once: Retries can repeat execution.
  • Putting huge Eloquent graphs in a job payload: Serialization becomes fragile and stale.

Follow-up Questions

  • Why use an ID rather than a model graph? (Answer: Reload current data inside the worker.)
  • What controls retry delay? (Answer: The job’s backoff configuration.)