Event Queue Bundle Laravel Package

Getting Started

• Install and register. composer require symfony-bundles/event-queue-bundle, then add the bundle to AppKernel (or bundles.php on Symfony 4). This package predates Flex, so there is no recipe — you wire the bundle manually.
• Look at the bundle’s README and DependencyInjection/Configuration.php first. The package is small and lightly documented; the config tree in Configuration.php is the fastest way to learn which transport, connection, and consumer options are actually supported. Do not assume it wraps Enqueue or Symfony Messenger — it is its own thin abstraction.
• Check the composer.json before committing. Last release is 2017-10-17, so it targets Symfony 3.x/early 4.x and PHP 7.0/7.1 era. Verify constraint compatibility before pulling it into a current project.
• First use case: fire-and-forget events. The core value proposition is dispatching an event without running its listeners synchronously in the request. Publish a domain event to the queue in your controller/service, then let a worker consume and dispatch it. This is the same mental model as Laravel’s dispatch(new Job) — except here you are queuing events that Symfony’s EventDispatcher later fans out to listeners.
• Sanity-check the consumer command. Once configured, confirm the bundle registers a console command (typically event-queue:consume or similar) by running bin/console list. That command is your worker and the thing you will run under supervisor/systemd in production.

Implementation Patterns

• Publish-side pattern — enqueue, don’t dispatch. Replace $dispatcher->dispatch('order.placed', $event) with a call that pushes the event onto the configured queue. Keep the event class a plain serializable DTO — no entities, no service handles, no closures. Store IDs and re-fetch on the consumer side.
• Consumer-side pattern — worker as the dispatcher. The worker reads messages, deserializes the event, and calls the standard EventDispatcher. Listeners registered normally (services tagged kernel.event_listener) then run against the queued event. This means your listener code does not change — only the dispatch path does.
• Separate "publish" services from "handle" services. Register a small EventQueuePublisher wrapper in your app so call sites never touch the bundle’s internals directly. If you later migrate to Symfony Messenger or Enqueue, you swap one class.
• Transport integration. Configure the queue transport (array/in-memory for tests, Redis/AMQP/DB for real deployments) via the bundle config. Keep transport credentials in env vars, not the bundle config — the config file should reference %env(...)%.
• Testing pattern. Use the in-memory/array transport in test env so unit and functional tests never touch a broker. Have your publisher interface mocked in listener tests; have the consumer tested separately with a fixed fixture message.
• Supervisor/systemd recipe. Run N worker processes, each with --time-limit or equivalent (if supported) and --memory-limit if the bundle exposes it. Wrap with restart policy. This is exactly how you would run php artisan queue:work.
• Routing events to handlers. If the bundle supports per-queue consumers, partition by domain (e.g. orders, billing) so a backlog in one domain does not stall another.
• Integration tip for mixed stacks. Because it plugs into Symfony’s EventDispatcher, you can keep synchronous listeners for latency-sensitive work and only queue the fan-out listeners (analytics, notifications, audit). Do not queue everything — queued events are eventually consistent and harder to trace.

Gotchas and Tips

• This is effectively unmaintained. Last release in 2017, 25 stars. Treat it as a learning reference or a legacy-project dependency, not something to introduce into a greenfield Symfony 5/6/7 app. Prefer Symfony Messenger or Enqueue for new work.
• Version drift is the real pitfall. Symfony 4+ removed AppKernel conventions; Symfony 5+ changed EventDispatcherInterface signatures (dispatch($event, $name) argument order). This bundle predates those changes — expect fatal errors on modern Symfony until you audit the dispatch calls.
• Serialization is your biggest hidden cost. Events must be fully serializable. Doctrine entities with proxies, \DateTime subclasses without timezone handling, and objects holding EntityManager references will deserialize badly. Use scalar DTOs and re-fetch entities by ID in listeners.
• Failures are silent by default. With direct dispatch, exceptions bubble in the request. With the queue, a listener exception may only surface in the worker log. Route worker output to a dedicated log channel and monitor dead-letter behavior (if any).
• Worker memory leaks. Long-running consumers accumulate memory in Doctrine’s identity map. If the bundle exposes --memory-limit, use it; otherwise restart workers periodically via supervisor.
• Debugging queued events. You cannot breakpoint the producing request and the consuming worker in one shot. Add correlation IDs to event payloads and log them at publish and consume time. This is the single most useful investment.
• Config quirks. Because the bundle is lightly documented, verify defaults in Configuration.php rather than the README. In particular, confirm the default transport name and whether the dispatcher path is overridden globally — a careless config can silently route all events through the queue.
• Extension point. The publisher/consumer classes are the intended seams. If you need custom routing or retry logic, decorate the publisher service instead of forking the bundle.
• Migration tip. If you do adopt it, abstract behind your own EventPublisher interface on day one. That keeps the exit to Symfony Messenger a one-file change when you inevitably outgrow it.