How do events and listeners work?

Question

Accepted Answer

Laravel's **events and listeners** implement the observer pattern — you **dispatch an event** when something notable happens, and one or more **listeners** react to it. This decouples code: the event source doesn't need to know who responds, enabling clean separation of concerns.

## Defining an event and a listener

```php
// the event — a simple data carrier for "something happened"
class OrderShipped {
    public function __construct(public Order $order) {}
}

// a listener — reacts to the event
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// generate with: php artisan make:event / make:listener
```

## Dispatching the event

```php
// when the order ships, DISPATCH the event — all listeners run
OrderShipped::dispatch($order);
// or: event(new OrderShipped($order));
```

Dispatching the event triggers all its registered listeners. The order-shipping code just announces what happened — it doesn't know (or care) that emails, analytics, or other reactions occur.

## Multiple listeners for one event (decoupling)

```php
// one event can have MANY listeners — each a separate concern
OrderShipped → SendShipmentNotification    // email
            → UpdateInventory               // adjust stock
            → RecordAnalytics               // log the event
// add reactions without modifying the order-shipping code
```

This is the key benefit: you can add new reactions (a listener) to an event without touching the code that dispatches it — clean, extensible decoupling.

## Queued listeners (async)

```php
class SendShipmentNotification implements ShouldQueue {   // run the listener in the BACKGROUND
    public function handle(OrderShipped $event): void { ... }
}
```

Implementing `ShouldQueue` makes a listener run **asynchronously** via the queue — so slow reactions (sending email) don't delay the response.

## Why it matters

Events and listeners are a useful Laravel feature for **decoupling** code — letting different parts of an application react to occurrences without tight coupling, which is valuable for cross-cutting reactions and keeping code maintainable.

Understanding them is helpful for both using them and recognizing them in codebases: the pattern lets you dispatch an event when something significant happens (an order ships, a user registers) and have multiple independent listeners react (send email, update inventory, record analytics), each handling a separate concern.

The key benefit is **extensibility through decoupling** — you can add new reactions by registering a listener without modifying the code that dispatches the event, keeping concerns separated and the dispatching code focused.

The ability to make listeners **queued** (`ShouldQueue`) so they run asynchronously is also important, letting slow reactions (emails, external API calls) happen in the background without delaying the user's response.

Knowing how events/listeners work, their decoupling benefit, and queued listeners for async processing is valuable knowledge for building well-structured, extensible Laravel applications. (As with signals in other frameworks, the caveat is that events create implicit, action-at-a-distance behavior that can be harder to trace — so they're best used for genuine cross-cutting decoupling rather than as a default for all post-action logic, where explicit code is often clearer.)