Jobs (Queues) vs. Events
When to use each one?
When a heavy task needs to run outside the main request-response flow, or multiple actions need to occur when something happens, you have two main options: jobs and events. They serve different purposes.
Jobs
A job is a task that runs in the background, either on a schedule or triggered outside the main request-response cycle. Jobs handle resource-intensive, time-consuming, or non-urgent processes.
Use cases:
- Scheduled tasks (cron jobs)
- Processing that doesn't need to run immediately
- Large file operations (PDFs, images)
- Syncing with third-party services
Example: A system that generates and emails financial reports every night at midnight. No user action triggers it - it runs on schedule.
Events
An event is a signal that something has happened in your application. Events can be triggered by users or by the system. An event doesn't do anything by itself - one or more listeners react to it.
Events decouple your logic. Instead of hardcoding all actions inside one method, you fire an event and let other parts of the system respond independently.
Use cases:
- Broadcasting when a specific action occurs (like
UserRegistered) - Triggering multiple follow-up actions
- Separating concerns between modules
Example: When a user registers, a UserRegistered event fires. Different listeners can send a welcome email, create an
audit log, and notify an admin - all independently.
You can combine both patterns. An event fires when a user performs an action, and one of the listeners queues a job to run in the background, like sending a welcome email asynchronously.
Jobs are like an alarm clock that rings at the same time every day, whether you're awake or not. Events are like a doorbell - they ring when pressed, and everyone inside hears it.
When to use each
Use a job when you need to:
- Perform heavy or background tasks
- Execute one-off tasks with no notification requirement
- Retry failed operations
- Run scheduled processes
Use an event when you need to:
- Trigger multiple reactions from one action
- Broadcast that something happened
- Decouple business logic across modules