Queued listeners in Laravel - Step-by-Step Execution

Concept Flow - Queued listeners

Event fired

↓

Check listeners

↓

Is listener queued?

No→Run listener immediately

Yes↓

Push listener job to queue

↓

Queue worker picks job

↓

Run listener asynchronously

↓

Listener finishes

When an event is fired, Laravel checks its listeners. If a listener is queued, it is sent to the queue to run later asynchronously. Otherwise, it runs immediately.

Execution Sample

Laravel

Event::dispatch(new UserRegistered($user));

// Listener with ShouldQueue interface
use IlluminateContractsQueueShouldQueue;

class SendWelcomeEmail implements ShouldQueue {
  public function handle(UserRegistered $event) {
    Mail::to($event->user->email)->send(new WelcomeEmail());
  }
}

This code fires a UserRegistered event. The SendWelcomeEmail listener is queued and runs later to send an email.

Execution Table

Step	Action	Listener Queued?	Queue Action	Listener Execution
1	UserRegistered event fired	N/A	N/A	N/A
2	Check SendWelcomeEmail listener	Yes	Push job to queue	Not run yet
3	Queue worker picks SendWelcomeEmail job	Yes	Job dequeued	Listener handle() runs
4	SendWelcomeEmail listener finishes	Yes	Job completed	Email sent to user
5	No more listeners	N/A	N/A	Event processing done

💡 All listeners processed; queued listeners run asynchronously by queue worker.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Event	Not fired	Fired	Fired	Fired	Processed
Listener Queue Status	N/A	Queued	Dequeued	Completed	Done
Email Sent	No	No	No	Yes	Yes

Key Moments - 3 Insights

Why doesn't the listener run immediately when queued?

Because queued listeners are pushed to a job queue (see execution_table step 2), they run later asynchronously when the queue worker processes them (step 3).

How does Laravel know to queue a listener?

Listeners that implement the ShouldQueue interface are automatically queued (execution_table step 2 shows this check).

What happens if the queue worker is not running?

Queued listeners stay in the queue and do not run until a queue worker picks them up (execution_table step 3).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the listener actually run?

A Step 3

B Step 2

C Step 1

D Step 5

💡 Hint

Check the 'Listener Execution' column in the execution_table for when handle() runs.

According to the variable tracker, when is the email sent to the user?

A After Step 2

B After Step 4

C After Step 3

D At Start

💡 Hint

Look at the 'Email Sent' row in variable_tracker to see when it changes to 'Yes'.

If the listener did NOT implement ShouldQueue, what would change in the execution table?

A Queue worker would pick job at Step 3

B Listener would be queued anyway

C Listener would run immediately at Step 2

D Event would not fire

💡 Hint

Refer to the 'Listener Queued?' column in execution_table and how it affects queue action.

Concept Snapshot

Queued listeners in Laravel run asynchronously.
Listeners implementing ShouldQueue are pushed to a job queue.
Queue workers run these listeners later.
Non-queued listeners run immediately.
This improves app responsiveness by deferring slow tasks.

Full Transcript

In Laravel, when an event is fired, the framework checks all listeners attached to it. If a listener implements the ShouldQueue interface, Laravel pushes it as a job to the queue instead of running it immediately. This means the listener's handle method runs later when a queue worker picks up the job. This process helps keep the app fast by deferring time-consuming tasks like sending emails. The execution table shows the event firing, listener queuing, queue worker processing, and listener completion. The variable tracker follows the event state, listener queue status, and email sending status. Key moments clarify why queued listeners don't run immediately and how Laravel detects queued listeners. The visual quiz tests understanding of when listeners run and how queueing changes execution.