Symfony Messenger Bridge Laravel Package

Technical Evaluation

Architecture fit. trollbus/symfony-messenger-bridge 0.1.0 is an initial release of an adapter layer that connects Symfony Messenger's transport/middleware contracts to Laravel's container and queue system (via Trollbus). Architecturally it is a bridge, not a framework — it should be an opt-in dependency, isolated behind an interface boundary, and evaluated on whether it lets us reuse Messenger's middleware stack (retry, dead-letter, envelope stamps) without leaking Symfony conventions into domain code. Because it sits between two opinionated buses, the primary fit question is which side owns message dispatch semantics in our codebase.

Integration feasibility. Feasible for a Laravel 10/11 + PHP 8.1+ stack, but this is a 0.1.0 with no documented feature set in the release notes — the changelog link is the only artifact. That is not sufficient evidence to scope work. We cannot yet confirm supported Messenger versions, transport coverage (AMQP, Redis, Doctrine, SQS), or whether it supports Symfony's #[AsMessageHandler] attribute or requires explicit handler registration.

Technical risk. High for planning purposes, low-to-moderate in practice:

• Pre-1.0 API instability. Any 0.x release may break on minor bumps. Pin exactly and treat upgrades as integration work.
• Dual-framework coupling. Bugs may originate in Laravel's container, Messenger's middleware, or the seam between them; triage spans two ecosystems.
• Single-maintainer / young project. Bus-factor and long-term support are unproven.
• Semantic drift. Messenger's retry/failure-transport model differs meaningfully from Laravel's failed_jobs; a bridge must pick a winner, and the choice affects operational tooling.

Key questions.

1. Which Messenger transports and middleware are actually supported at 0.1.0?
2. Does it map failures to Laravel failed_jobs, Messenger's failure transport, or both?
3. Are Messenger envelope stamps and HandledStamp/SentStamp metadata preserved end-to-end?
4. What is the supported Laravel / PHP / Symfony Messenger version matrix?
5. Is dead-letter replay supported through an Artisan command, or only via Symfony tooling?
6. What is the maintainer's stated path to 1.0 and backward-compatibility policy?

Integration Approach

Stack fit. Appropriate only where we already have a Laravel app and a genuine need for Messenger-compatible message contracts — most commonly interoperating with an existing Symfony service, or consuming a shared library that emits Messenger envelopes. If our requirement is simply async jobs in Laravel, native queues are the lower-risk choice and this package adds an unnecessary abstraction.

Migration path. Greenfield adoption is straightforward: add the dependency, publish config, register the service provider, and route a single low-risk message type through it behind a feature flag. Brownfield migration of existing Laravel jobs should be avoided initially — the contract shapes differ, and rewriting handlers before the package stabilizes invites rework on the next minor release. For teams coming from Symfony, the reverse applies: keep Messenger handler signatures intact and adapt at the transport boundary rather than rewriting handlers.

Compatibility. Verify against the pinned versions in composer.json before committing. Explicitly test: Laravel queue driver(s) actually in use, PHP version, and the exact Messenger version. Treat the absence of a published compatibility matrix at 0.1.0 as a gap requiring our own verification, not as an assumption of broad support.

Sequencing.

1. Spike (1 sprint). Timeboxed proof of concept: dispatch one message, verify retry, verify failure capture, verify serialization round-trip. Produce a written findings note.
2. Contract review. Decide whether Messenger envelopes or Laravel jobs are the canonical internal contract; document the decision.
3. Pilot. One non-critical async workflow in staging, with the feature flag and a documented rollback to native queues.
4. Production. Only after a stable 0.2.x+ or an explicit maintainer commitment on API stability, and only with version pinning plus a lockfile.

Operational Impact

Maintenance. Expect to own more than usual. Pin the exact version, subscribe to releases, and budget for reading diffs on every bump — there is no LTS signal. Add the package to the dependency-review checklist and record the maintainer as a named risk in the service's ownership doc.

Support. Community-only by default: GitHub issues, no vendor SLA. Internal escalation path is our own engineers, who will need working knowledge of both Laravel queues and Messenger middleware. Identify at least two people; a single knowledgeable engineer is an operational single point of failure.

Scaling. Throughput and scaling characteristics are inherited from the underlying Laravel queue driver, not from the bridge — so horizontal scaling follows our existing worker topology. The open question is failure-transport behavior under load: confirm that retries are bounded, backoff is configurable, and a poison message cannot loop indefinitely across the bridge seam. Validate with a deliberate poison-message test in staging before production.

Failure modes.

• Silent message loss if the bridge does not persist failures to a recoverable store — highest-severity risk, must be tested explicitly.
• Duplicate delivery under at-least-once semantics; handlers must be idempotent regardless of the bridge.
• Serialization breakage on version upgrades (envelope format changes), which can strand in-flight messages during a deploy — drain queues before upgrading.
• Retry amplification if both Laravel and Messenger retry layers are active; ensure only one is authoritative.
• Dependency conflict on a Messenger or Laravel minor bump, blocking unrelated upgrades.

Ramp-up. Low conceptual cost for engineers already fluent in Laravel queues; meaningful cost for anyone who has not worked with Messenger's middleware and envelope model. Budget roughly a day of onboarding reading plus the spike output. Publish a short internal runbook covering: how to dispatch, how to inspect failures, how to replay, and how to roll back to native queues. The runbook is the deliverable that makes this package operationally safe at 0.1.0 — without it, the package should not reach production.