Notifications vs events — when to use which

Concept

Notifications vs events — understanding when to use each prevents architectural confusion.

Events model things that happened in your domain. They're consumed by listeners inside your application that react to those things. Events are internal signals — they don't inherently result in a user-facing communication.

Notifications are specifically about delivering messages to users through external channels — email, SMS, push notification, Slack, in-app database notification. They're the "output" side of the system.

The relationship: An event can trigger a notification, but they're different layers. OrderPlaced is an event. The SendOrderConfirmationEmail listener sends a notification. Or you can send a notification directly from a controller without an event at all.

When to use events instead of notifications: When you need to trigger multiple independent internal reactions that don't all result in user messages. UserRegistered event: one listener syncs CRM, another provisions resources, a third sends a welcome notification. The event is the signal; the notification is just one possible reaction.

When to use notifications directly: When you simply need to message a user without complex internal system reactions. $user->notify(new PasswordChanged()) in a controller. No event needed if nothing else cares that the password changed.

Key distinction: Events are for decoupling internal components. Notifications are for user-facing communications. They're complementary, not alternatives.

Code Example

<?php
// Direct notification — simple, no event needed
class PasswordController extends Controller
{
    public function update(Request $request)
    {
        $user = $request->user();
        $user->update(['password' => bcrypt($request->password)]);

        // Simple, direct notification — no event needed
        $user->notify(new \App\Notifications\PasswordChanged());

        return redirect()->back()->with('status', 'Password updated!');
    }
}

// Event-triggered notification — when multiple systems care
class OrderController extends Controller
{
    public function store(Request $request)
    {
        $order = Order::create($request->validated());
        event(new \App\Events\OrderPlaced($order)); // fires multiple listeners
        return response()->json($order, 201);
    }
}

// Listeners — each does its own thing
class NotifyCustomerOfOrder
{
    public function handle(\App\Events\OrderPlaced $event): void
    {
        $event->order->customer->notify(new \App\Notifications\OrderConfirmation($event->order));
    }
}
class UpdateInventoryOnOrder { public function handle(...): void { /* ... */ } }
class SyncOrderWithCrm { public function handle(...): void { /* ... */ } }

// Rule of thumb:
// Is it purely about messaging ONE user → use notification directly
// Do multiple internal systems care → use event + listener that sends notification
// Do you need email + SMS + in-app → one notification class handles all channels