What this prompt does
This prompt designs a complete queue-based, event-driven system in Laravel for a feature that shouldn't block the request cycle. It produces the events, queued listeners, job classes with retry logic, failure handling, an event subscriber, Horizon configuration, an event-log migration, and a monitoring widget — plus tests using Queue::fake(). The goal is a pipeline that stays healthy under real load rather than a single fire-and-forget job.
The variables tune reliability and routing. [feature_description] names the workflow, [events_list] becomes the actual event classes, and the listeners are configured with [queue_driver] as the connection and [queue_name] as the queue so work lands on the right worker. [max_tries] and [backoff_strategy] control retry behavior, which is where most home-grown queues fail — too few tries drops work, no backoff hammers a failing dependency. [batch_operation] defines what gets processed in a batch. Because retries, backoff, and failure handling are designed up front with Horizon in mind, the output is built to survive transient failures.
When to use it
- Moving slow work (emails, fulfilment, webhooks) out of the HTTP request cycle
- Designing an event-driven flow where one action triggers several downstream listeners
- Setting up jobs with sensible retry and backoff instead of naive immediate retries
- Configuring Horizon to manage workers across named queues
- Adding failed-job handling and notifications so silent failures don't pile up
- Batch-processing bulk operations like sending many notification emails
Example output
You get a set of event classes from your [events_list], queued listener classes pinned to your [queue_driver] connection and [queue_name], job classes declaring [max_tries] and the [backoff_strategy], a failed-job handler with notifications, an event subscriber, a Horizon config block, a migration for an event-log table, and a monitoring widget. Tests use Queue::fake() to assert jobs are dispatched without actually running them. The result reads as a coherent pipeline rather than scattered dispatch calls.
Pro tips
- Name
[events_list]as past-tense domain facts (OrderPlaced, PaymentProcessed) so listeners read naturally and the flow is easy to trace - Match
[queue_driver]to your infrastructure — redis is standard for Horizon; database queues won't give you Horizon's dashboard - Set
[max_tries]and[backoff_strategy]to fit the failure mode: exponential backoff is right for flaky external APIs, not for permanent errors - Use a dedicated
[queue_name]per workload so a flood of one job type can't starve another - Keep
[batch_operation]genuinely batchable; wrapping unrelated work in a batch just complicates failure handling - Rely on Queue::fake() in tests to assert dispatch and arguments without spinning up real workers, then add a few integration runs for the happy path
