Laravel Queued Notifications: Dispatch After the Business Record Commits

A queued notification should describe a business change that actually committed. In Laravel, dispatching a job inside a database transaction can let a worker run before the record is available unless the dispatch policy accounts for that boundary.

The Laravel queue documentation describes after-commit dispatch at the connection or individual-job level. Use the behavior supported by your installed version and verify the actual queue configuration.

Identify the event being announced

Name the business transition precisely: an estimate was approved, an invoice was issued or an export became available. Avoid treating a button click as the event if the database operation can still fail.

YourBiz describes estimates, customer approval and invoices, and has a Laravel association. Its queue design is not public in the listing. The workflow illustrates why a customer should not receive an approval message for a transaction that was rolled back.

The notification should refer to the committed record and relevant revision.

Defer work until the record exists

Review where the job is dispatched relative to the transaction. Configure or request after-commit behavior when the job depends on changes inside that transaction.

Then test a successful commit and an intentional rollback. The worker should see the committed state, and the rollback should not produce the corresponding notification.

Do not assume local testing proves this boundary if the development queue executes synchronously. Exercise the asynchronous arrangement used by the deployment.

Preserve the intended message

Decide whether the notification describes the state at the event time or the latest state when the worker runs. Both can be legitimate, but they are different contracts.

Store a suitable event reference or snapshot of the necessary non-sensitive facts. Avoid serializing an entire mutable record simply because it is convenient.

If an estimate changes after approval, the notification should not silently describe a different revision.

Protect delivery from repeats

After-commit dispatch solves one ordering problem; it does not by itself guarantee that an external message is delivered exactly once.

Give delivery a durable identity and define how retries recognize completed work. Test a provider response timeout after the provider may have accepted the message.

Keep reconciliation information without storing unnecessary customer content in logs.

Test the full workflow

Use a synthetic business record in an isolated environment. Exercise rollback, delayed worker execution, repeated delivery attempts and an unavailable provider.

Check the resulting record state, queued work and sent-message count. A successful request response should not be the only evidence.

The companion Laravel scheduler guide covers recurring tasks, while the existing Laravel performance guide explains where queueing can reduce request-path work.

Record which configuration controls dispatch and how the worker loads it after deployment. Stale worker configuration can undermine a correct source change.

A reliable notification pipeline connects a committed business fact to an intentional delivery attempt. Keeping that connection explicit helps the product remain understandable when transactions fail, queues slow down or providers ask for retries.

Retain the rollback fixture when new notification types are added; it catches mistakes that an ordinary successful submission cannot reveal.