← All insights
ENGINEERING JOURNAL / Laravel Engineering

Laravel Queues: Dispatch Jobs After Database Commit

Avoid jobs reading uncommitted Laravel records. Plan commit timing, repeat-safe processing and a recovery check for background workers.

CI/CD / ARTIFACT PROMOTION
Laravel Queues: Dispatch Jobs After Database Commit — Clouvenix engineering illustration

Context

An order is saved inside a database transaction and a receipt job is dispatched immediately. Under light testing, the worker may start late enough that everything looks correct. Under different timing, it can look for the order before that transaction has committed.

Separate persistence from follow-up work

Draw the order workflow as three responsibilities: accept and validate the request, persist the business change, then perform follow-up delivery. Identify which background operations need committed data and which can safely run independently.

Laravel documents queue dispatch after commit, through connection configuration or an individual job's afterCommit behavior. Its queue guide explains that a worker can otherwise run before the parent transaction finishes. The exact configuration belongs in the documentation for the Laravel version deployed.

Make the job safe to repeat

Commit timing does not solve every delivery failure. A receipt provider may accept a message just before the worker loses its connection. Retrying that job can produce another receipt unless the business operation is designed to recognize an already completed delivery.

Choose a durable receipt identity, store a clear delivery state and distinguish retryable failures from invalid recipient data. Avoid placing a full secret-bearing request or an unnecessary customer record in the queue payload. Give operators a useful reference without exposing confidential content.

Exercise the important timings

  • Delay the transaction while a worker is already available.
  • Roll back the order and check that no success receipt is sent.
  • Stop a worker during a job, restart it and inspect the result.
  • Replay the same business request and check for duplicate side effects.
  • Confirm that failed jobs are visible to the operating team.

Use an isolated environment and a non-delivering email adapter for these tests. Record the expected outcome before running them; a growing queue is a symptom, not a diagnosis.

Plan the operational handover

A release needs compatible worker code as well as compatible web code. Document how workers restart, how their health is checked, where failed work is reviewed and who may replay it. Test with the queue backend used in production rather than relying only on a synchronous development path.

See Laravel development and DevOps automation for related delivery scope.

Technical reference

Laravel queue documentation: jobs and database transactions. This reference is version-specific; confirm behavior against the installed release.