In Laravel, how do you create a queued job with make:job and dispatch it so it runs on a worker instead of inside the request?

## What make:job generates A **job** in Laravel is a plain PHP class that describes one unit of background work. `php artisan make:job GenerateInvoicePdf` creates it in `app/Jobs` (the directory is created on first use). In Laravel 13 the generated class: - implements `Illuminate\Contracts\Queue\ShouldQueue` — the **marker interface** that tells the bus dispatcher to push the job onto a queue instead of running it now; - uses `Illuminate\Foundation\Queue\Queueable`, one trait that pulls in `Dispatchable` (the static `dispatch()` family), `InteractsWithQueue` (`release()`, `delete()`, `attempts()` on the running job), the bus `Queueable` (connection, queue, delay, chain settings) and `SerializesModels`; - has an empty constructor and a `handle(): void` method. The data the job needs goes into the **constructor**, usually as promoted public properties. Services go into `handle()` as type-hinted parameters, and the service container injects them when the worker runs the job. `make:job --sync` generates the opposite: a class with only `Dispatchable` and no `ShouldQueue`, meant to run in-process. ## What dispatch() actually does 1. `GenerateInvoicePdf::dispatch($invoice)` calls `new static(...$arguments)`, so the arguments go straight to the constructor. 2. It wraps the job in a `Illuminate\Foundation\Bus\PendingDispatch` and returns it. Nothing has been queued yet. 3. You chain configuration onto it: `->onQueue('billing')`, `->onConnection('redis')`, `->delay(now()->addMinutes(5))`, `->afterCommit()`. 4. When the `PendingDispatch` is destroyed — normally at the end of the statement — its destructor hands the job to the bus dispatcher. 5. The dispatcher checks `instanceof ShouldQueue`. If true, the job is **serialized** into a payload and pushed to the chosen connection and queue; if false, `handle()` runs immediately in the current process. Because the push happens in the destructor, storing the result (`$pending = GenerateInvoicePdf::dispatch($invoice);`) delays the push until that variable goes out of scope. The global `dispatch(new GenerateInvoicePdf($invoice))` helper behaves the same way. ## Where the job goes A **connection** is a backend defined in `config/queue.php`; a **queue** is a named pile of jobs on that connection. The Laravel 13 skeleton ships `QUEUE_CONNECTION=database` in `.env.example`, and its migrations already create the `jobs`, `job_batches` and `failed_jobs` tables, so a fresh app queues into a database table with no extra infrastructure. | Setting | Per dispatch | On the class (Laravel 13) | |---|---|---| | Queue name | `->onQueue('billing')` | `#[Queue('billing')]` | | Connection | `->onConnection('redis')` | `#[Connection('redis')]` | | Delay | `->delay(300)` or a `DateTimeInterface` | `#[Delay(300)]` (seconds) | A value set at dispatch time overrides the class attribute. The attributes live in `Illuminate\Queue\Attributes`. A job sent to `billing` only runs if some worker listens on `billing`; which queues a worker drains, and in what order, is worker configuration. ## Common first-job mistakes - **No `ShouldQueue`.** The class still has `dispatch()`, but the dispatcher runs `handle()` inline, and the request waits for it. - **No worker.** On the database connection, jobs accumulate as rows in `jobs` until a `php artisan queue:work` process (or `php artisan dev`, which starts one) consumes them. - **Unserializable constructor data.** The payload is JSON with a serialized command inside; open resources cannot be serialized, and the docs say raw binary data should be `base64_encode`d first. - **Expecting a return value.** `dispatch()` returns the `PendingDispatch`, not the result of `handle()`; the work happens later, in another process. - **Tests that seem synchronous.** The skeleton's `phpunit.xml` sets `QUEUE_CONNECTION=sync`, so jobs run inline during tests and a delay has no effect there. ## What the worker does with it A worker process started with `php artisan queue:work` polls its connection, reserves the next available job and rebuilds it: - it unserializes the command from the payload, and `SerializesModels` re-fetches any Eloquent models by key; - the service container calls `handle()`, resolving every type-hinted parameter, so the job can ask for a mailer, an HTTP client or your own service class; - when `handle()` returns, the job is deleted from the queue; - when it throws, the worker either releases it for another attempt or records it in `failed_jobs`, depending on how many tries the job and the worker allow. Because the worker is a long-lived process that booted the application once, a code change is only picked up after the worker restarts — which is why deployments restart queue workers. ## Why the split matters Queuing moves slow or failure-prone work — PDF rendering, third-party API calls, mail — out of the request, so the response returns quickly and the work can be retried by the worker. The price is that the job runs later, in a different process, against whatever the database holds at that moment. Everything else in this area — the transaction timing, model serialization, uniqueness — follows from that one fact.