Mongodb Messenger Transport Laravel Package

Technical Evaluation

Architecture fit. Unchanged in kind: this remains a Symfony Messenger transport, not a Laravel queue driver. It plugs into symfony/messenger as a transport factory and depends on facile-it/mongodb-bundle, a Symfony bundle requiring kernel/bundle registration lifecycle. Release 1.9.0 reinforces this — the package now extends Symfony\Component\DependencyInjection\Extension\Extension (#105), which is the canonical Symfony bundle configuration-loading mechanism. Laravel has no equivalent bundle/extension system, so the package still cannot be installed and auto-wired in a standard Laravel app. Leveraging it in Laravel still means either (a) adopting symfony/messenger standalone alongside Laravel's container — high-friction — or (b) extracting/forking the transport class into a custom Laravel Queue connector. The TPM should continue to treat the "Laravel" framing as aspirational until the team confirms the codebase is actually Symfony Messenger-based.

Integration feasibility. If the target is genuinely Laravel, feasibility remains low out of the box and requires custom engineering. If the target is a Symfony service (or a Laravel app already running Symfony Messenger for domain events), feasibility is moderate and slightly improved by 1.9.0: the DI extension refactor means the bundle's configuration wiring is on the supported, non-deprecated path, reducing the chance of breakage on future Symfony majors. Hard prerequisites are unchanged: the mongodb PHP extension, Doctrine MongoDB ODM, and a supported Symfony major. Updated constraint: Symfony >=5.4 only — 1.9.0 explicitly drops support for Symfony below 5.4 (#78). The prior "verify 6.x/7.x vs. app version" question is now answered at the floor (5.4) but still must be checked at the ceiling against the app's pinned Symfony version.

Technical risk. Adoption signals remain weak: ~7 stars, 0 dependents, single maintainer surface. 1.9.0 provides one modest positive signal — a deprecation-driven refactor merged from a community contributor — indicating the project is not fully dormant and does track upstream Symfony direction. It does not change the core risk profile: no evidence of production scale, and delivery semantics (atomic claim via findOneAndUpdate, visibility timeout/redelivery, at-least-once duplicate handling, dead-letter behavior) remain unvalidated by a broad user base. Note the release is versioned as a minor (1.9.0) but contains a backward-incompatible drop of Symfony <5.4; per semver this arguably warranted a major bump, which tells us to read release notes carefully rather than trust version numbers when pinning.

Key questions for the team.

1. Are we on Laravel Queues or Symfony Messenger today? If Laravel Queues, why is this package in scope at all?
2. Is MongoDB already a mandated primary datastore, or are we adding it purely as a queue?
3. What throughput and latency SLOs does the async workload require? Polling transports have a floor on latency and a ceiling on throughput without tuning.
4. Who owns the fork/patch if upstream stalls? Is there budget for that?
5. New: What is our exact Symfony version? 1.9.0 requires >=5.4 and silently drops older support — if any service in our estate is on 5.3 or below, this release is unusable there and prior versions become the only option (and a permanently unsupported branch).
6. Does our Symfony version's DependencyInjection\Extension API match what 1.9.0 targets, and has the mongodb-bundle peer been validated against it?

Integration Approach

Stack fit. Unchanged. Good fit only where MongoDB is already the system of record and Symfony Messenger is already the message bus — there it removes an entire piece of infrastructure. In a Laravel-native app the fit remains poor: introducing a Symfony transport bypasses Horizon, queue:work semantics, failed_jobs tables, and Laravel's retry/backoff configuration. 1.9.0 does nothing to close that gap.

Migration path. Same three options, same order of preference for a Laravel shop:

• Do not adopt. Use Laravel's Redis or SQS driver.
• Fork the transport into a Laravel queue connector. Port the claim/release logic into an Illuminate\Queue\Connector + Job pair. Estimate 1–2 sprints plus ongoing maintenance. Note: forking from 1.9.0 is preferable to earlier versions only if we're on Symfony 5.4+; otherwise fork from the last pre-1.9 tag and accept the now-avoidable deprecations.
• Adopt Symfony Messenger inside Laravel. Only viable if the team already runs Messenger.

For a Symfony service, migration is straightforward and now cleaner: install mongodb-bundle, add transport DSN/config, route message classes to the transport, run messenger:consume workers under Supervisor. The Extension refactor means config loading follows the modern bundle pattern, so a Symfony 7 upgrade path is less likely to strand us.

Compatibility. Release 1.9.0 gives us one hard data point and removes ambiguity elsewhere. Pin and verify:

• Symfony >=5.4 (confirmed floor; 1.9.0 is a breaking drop of 5.3 and below).
• Symfony ceiling — 6.x vs. 7.x is still not stated in the release notes; read composer.json and CI matrix directly.
• doctrine/mongodb-odm version and ext-mongodb.
• facile-it/mongodb-bundle peer constraint — 1.9.0's Extension change may require a matching bundle floor.

Because dependents are zero, there is still no public compatibility matrix; the team must read composer constraints and CI config rather than trust ecosystem testing. Treat 1.9.0 as a breaking upgrade on any service below Symfony 5.4 and gate it behind a deliberate pin-bump PR rather than an automated update.

Sequencing. (1) Confirm framework target and message-bus choice. (2) Inventory Symfony versions across all candidate services; anything <5.4 is out of scope for 1.9.0 and flags a broader platform-debt conversation. (3) 1–2 week spike on 1.9.0 in a non-critical worker: measure claim latency, duplicate rate under simulated worker crashes, collection growth, and confirm the new Extension wiring loads cleanly with our config. (4) Benchmark against Redis/SQS at expected peak throughput. (5) Decide adopt vs. fork vs. abandon, with spike data as the decision record.

Operational Impact

Maintenance. Still the dominant cost, but the picture is marginally better than the prior assessment. 1.9.0 shows a maintainer who responds to Symfony deprecations and merges community work, which lowers — but does not eliminate — the probability of the package stranding us on a future Symfony major. Assume no upstream SLA and plan for internal ownership: version pinning, patching, responding to MongoDB driver changes. Budget ~10–20% of one engineer per quarter, more during major framework upgrades. Add a specific line item: audit Symfony version support at each upstream release, since this maintainer ships breaking constraint changes under minor version numbers.

Support. Unchanged. GitHub issues only; no vendor contract, no security advisory process beyond standard GitHub flow. For a payments- or PII-adjacent pipeline this remains a governance gap to escalate rather than absorb.

Scaling. Unchanged: horizontal by adding consumers, contingent on atomic claim and correct indexes (compound index on availability/priority, TTL or cleanup job on completed messages). Watch collection growth, write-concern tradeoffs (majority costs latency; w:1 risks loss on failover), and polling load against replica-set read capacity.

Failure modes. Unchanged: at-least-once duplicates (all consumers must be idempotent); stuck messages from misconfigured visibility timeout; unbounded collection growth if cleanup fails silently; MongoDB outage taking the whole async pipeline down (no separate blast radius); index/collection contention at high insert rates. Add: a future Symfony major upgrade leaves us pinned to 1.9.x if upstream stalls — this release made that dependency explicit, and it is the most plausible near-term way this package becomes a liability.

Ramp-up. Moderate lift in a Symfony shop (Messenger envelopes, stamps, middleware, retry strategy, transport semantics) — unchanged. Higher in a Laravel shop, where engineers must learn a second messaging abstraction on top of the one Laravel already provides, with none of the expected tooling (Horizon, failed_jobs inspection). Budget 2–4 weeks to competence and longer to confident on-call coverage.