Product Decisions This Supports
- Broker selection decoupled from framework defaults. Symfony Messenger ships native transports for AMQP, Redis, Doctrine, SQS, Beanstalkd, etc. This adapter lets us target any broker Enqueue supports, so the broker decision becomes an infrastructure/ops decision rather than being dictated by what the framework happens to support. That is directly relevant when procurement, existing infrastructure, or a managed-service contract points at a broker Messenger doesn't cover natively.
- Migration without a rewrite. If we already run the Enqueue bundle (common in older Symfony estates), this is the cheapest path to adopt Messenger's handler/routing/middleware model while keeping existing exchanges, queues, and consumers alive. It enables a phased migration: producers move to Messenger's
routing: config first, Enqueue consumers keep draining in parallel, then consumers flip. This is a roadmap-enabling decision, not a feature decision — it turns a 2-quarter rewrite into incremental releases.
- Access to broker-level delivery semantics. Priority queues, delayed messages, message TTL, dead-letter exchanges, and topic-based fan-out are configured through the transport DSN (
?queue[name]=...&topic[name]=...) instead of being reimplemented in application code with scheduled commands and retry tables. That is a real reduction in custom code we'd otherwise own and test.
- Build vs. buy: buy. Writing and maintaining a Messenger transport for a non-native broker is one to two engineering weeks up front plus permanent ownership of serialization, reconnect, and prefetch edge cases. A ~200-line MIT adapter with a changelog and tagged releases is the cheaper option for a non-differentiating capability.
- Fan-out and multi-broker topologies. Because Enqueue abstracts the broker, we can route different message types to different brokers (e.g., high-volume telemetry to one backend, transactional events to another) using a single Messenger routing table — useful if we're consolidating after an acquisition or splitting a monolith by domain.
- Vendor-negotiation leverage. A working, tested fallback broker path is concrete evidence in pricing conversations that we are not captive. Even if we don't ship on it, the spike de-risks the renewal.
When to Consider This Package
Adopt when most of the following hold:
- We need a broker that Symfony Messenger does not support natively, or we already operate one (Enqueue covers AMQP variants, Redis, STOMP, SQS, Kafka, Google Pub/Sub, MongoDB, Gearman, Doctrine, filesystem).
- We require transport-level features — delay, priority, TTL, DLX, topic exchanges — and want them in configuration rather than application code.
- An Enqueue bundle already exists in the codebase, or will exist alongside, so the extra dependency is not net-new surface area.
- We're on a supported Symfony/Messenger version and can pin the adapter to a tagged release; the changelog and release cadence are the evidence to check first.
- Team has or can acquire basic operational fluency with the underlying broker (queue provisioning, monitoring, consumer supervision). This adapter is a bridge, not an abstraction that removes the need to know the broker.
Look elsewhere when:
- Greenfield with a natively supported broker. If AMQP, Redis, Doctrine, or SQS is acceptable, Messenger's native transport is simpler, first-party, and has far more documentation and community answers. Adding a bridge here is pure liability.
- You need a support contract or vendor SLA. This is an MIT community package; there is nobody to escalate to at 2am. That is fine for a commodity bridge, disqualifying for a tier-0 payment path without in-house capability.
- Dependents and bus factor are the deciding factor. Published dependents are effectively zero and stars are ~200. Verification note: the README's install command is
sroze/messenger-enqueue-transport, not enqueue/messenger-adapter — confirm which Packagist name we're actually pulling, because dependents/stars under the legacy name don't show up under the new one, and split identity is itself a maintenance signal worth a 15-minute check before we depend on it.
- You're on an old Symfony or an old Enqueue major. Version matrices for a bridge like this are narrow; validating a stray combination can cost more than the native transport rewrite.
- The real need is streaming/event-log semantics (replay, partitions, consumer groups). Use a purpose-built client and keep Messenger for task queues.
How to Pitch It (Stakeholders)
For executives (one paragraph): Our message queue is becoming the seam between our monolith and the services we're splitting out, and today the framework only speaks to a short list of brokers. This is a small, MIT-licensed, actively released adapter that lets Symfony's messaging layer talk to whichever broker our infrastructure team chooses, without changing application code. Practically it buys us two things: we can pick (or keep) a broker on cost and operational merit rather than framework convenience, and if we ever need to move, the change is configuration plus a queue drain instead of a rewrite. Cost is one Composer dependency and roughly two days of spike work to validate on our stack; the risk is that it's community-maintained, which we mitigate by pinning versions and keeping the broker swap as a documented one-line exit.
For engineering (what it actually is): a Messenger transport (enqueue://<transport>) that hands serialization and delivery to Enqueue. We keep Messenger's routing, handlers, middleware, and messenger:consume worker model unchanged; broker-specific settings live in DSN query parameters. Two constraints to design around: (1) the message envelope is serialized by Messenger and carried as an Enqueue message body, so swapping to a native transport mid-flight requires draining queues and a cutover, not a hot swap — plan that explicitly; (2) consumer lifecycle, reconnect, and prefetch behaviour are Enqueue's, not Messenger's, so our runbook and monitoring need to reflect that.
Ask: approve a time-boxed spike — stand up one non-critical async flow on the target broker, exercise retry, delay, and DLX, and document the transport-swap exit procedure. If the spike passes, adopt; if it doesn't, we've still learned what our native-transport fallback costs.