Messenger Mongo Bundle Laravel Package

Technical Evaluation

Architecture fit. The single most important finding is a framework mismatch: this is a Symfony Messenger transport, not a Laravel package. Laravel's queue abstraction (Illuminate\Queue, drivers, workers, Horizon, failed_jobs) has no awareness of Symfony\Component\Messenger. Nothing in this bundle registers a Laravel service provider, exposes a Laravel queue connector, or integrates with Laravel's retry/backoff/failure semantics. For a Laravel codebase, this is not a drop-in dependency — it is an adoption of a second, parallel messaging runtime. That is a legitimate architecture, but it is an architecture decision, not an integration detail, and should be framed to stakeholders as such.

Integration feasibility. Feasible but non-trivial:

• Symfony Messenger's core components (symfony/messenger, symfony/serializer, symfony/config, symfony/dependency-injection) are framework-agnostic and can run inside a Laravel app. The bundle itself, however, expects Symfony's kernel, bundle registration, and DI conventions. Expect to either (a) instantiate the transport/connection classes manually and wire a custom Laravel service provider, or (b) use Symfony's standalone MessengerPass/container in a separate worker process. Both are custom glue code we own.
• The bundle depends on mongodb/mongodb (the official PHP library). Laravel MongoDB users typically run mongodb/laravel-mongodb, which also pulls the same underlying ext-mongodb + library. Version alignment is likely workable but must be verified against our pinned Laravel and PHP versions; a Composer conflict here stalls the whole initiative.
• Practical fallback worth evaluating: use this bundle only as a failure/audit transport (the README's own rationale — persistent failed-message storage alongside an existing Mongo deployment) rather than as the primary work queue. That reduces blast radius and lets us pilot with low commit.

Technical risk.

• Category risk: MongoDB is a documented-mediocre queue. The README itself says so. Polling-based consumption, findOneAndUpdate-style reservation, and TTL-based cleanup do not give us the delivery guarantees or throughput profile of Redis/SQS/RabbitMQ.
• Maturity risk: 16 stars, 0 dependents, effectively a single-vendor (eMAG Tech Labs) internal tool open-sourced. No evidence of external production adoption. Bus factor of roughly one team.
• Pre-1.0 semantics risk: transport behavior around redelivery, reserved-message timeouts, and delayed retries must be verified empirically, not assumed. At-least-once delivery with possible duplicate processing is the safe assumption.
• Observability risk: no Horizon, no Laravel queue:monitor, no standard metrics. We would own dashboards and alerting from scratch.
• Security/supply-chain: MIT license is fine; low review surface, but also low scrutiny. Pin exact versions and audit.

Key questions to resolve before committing.

1. Do we already run MongoDB in production, and is it the same cluster we'd queue against? (Colocating a queue on a primary transactional cluster is a capacity and blast-radius concern.)
2. What is the actual message volume and latency requirement? If it is under a few messages/second with minutes-level latency tolerance, polling Mongo is acceptable; if it is high-throughput, this is the wrong tool.
3. Is there an existing Symfony Messenger footprint anywhere in the org, or would we be introducing the abstraction cold?
4. Who owns the fork if upstream goes quiet — do we have PHP/Symfony depth to maintain a transport?
5. What does "done" look like for a pilot — a single non-critical consumer with defined SLOs?

Integration Approach

Stack fit. Target stack is Laravel (assume 10/11) + PHP 8.x + existing ext-mongodb. Symfony components coexist with Laravel routinely, so a standalone Messenger worker process (separate from php artisan queue:work) is the cleanest fit. We should not attempt to shoehorn this into config/queue.php as a driver; that path leads to fighting Laravel's worker lifecycle. Treat the Messenger worker as a second runtime with its own supervisor/process manager entry, its own health check, and its own deployment artifact.

Migration path. Three options, in ascending cost:

1. Failure-sink only (recommended pilot). Keep Laravel's existing queue driver for dispatch, and mirror failed jobs into Mongo via this transport for durable inspection/audit. Lowest risk, validates the Mongo read/write path and index design, delivers value even if we stop there.
2. Single bounded context on Messenger. Move one low-volume, non-customer-facing consumer (e.g. notifications, reporting fan-out) onto Messenger + this transport, running parallel to Laravel queues. Proves operational ergonomics.
3. Full queue replacement. Only justified if Mongo is already mandated and throughput is modest. Not recommended as an initial step.

Compatibility work items. Lock PHP and Laravel versions; resolve mongodb/mongodb vs mongodb/laravel-mongodb version constraints in a spike branch; confirm ext-mongodb version parity across dev/CI/prod; validate serialization (Symfony Serializer vs Laravel's job serialization) for any message carrying Eloquent models — do not serialize Eloquent models across this boundary; pass IDs and rehydrate.

Sequencing.

1. Week 1 — dependency/Composer spike and a throwaway producer/consumer against a non-prod Mongo. Confirm it runs at all.
2. Week 2 — index design (reservation/visibility field, availableAt, TTL on completed), load test at 5–10× expected peak, measure write amplification on the Mongo cluster.
3. Week 3 — observability: consumer lag, reservation timeouts, duplicate-rate, collection growth, dead-letter counts. Define alert thresholds.
4. Week 4 — pilot the failure-sink use case in one service.
5. Gate review before any primary-queue usage.

Operational Impact

Maintenance. We are effectively adopting a lightly-maintained dependency with no external dependents. Budget for the real possibility of vendoring or forking the transport class. Pin the version, and add it to the dependency-review list with an explicit owner and a quarterly upstream check. Note the last release date (2026-01-14) suggests recent activity, but activity ≠ stability; verify changelog cadence and issue responsiveness before committing.

Support. Community support is thin — no Stack Overflow corpus, no Laravel-ecosystem familiarity. Internal runbooks must be written by us: how to inspect the collection, how to requeue a stuck message, how to purge, how to interpret reservation timeouts. On-call will be learning a bespoke system, not a well-trodden one.

Scaling. Scaling characteristics are driven by Mongo, not by the bundle: polling frequency sets baseline read load; worker concurrency sets reservation contention; the queue collection adds write pressure to a cluster that may also serve product traffic. Horizontal scaling means more workers contending on the same documents — verify reservation atomicity under concurrency before scaling out. Storage growth is unbounded unless TTL/archival is configured and tested.

Failure modes to design for.

• Duplicate delivery / at-least-once processing — handlers must be idempotent. Non-negotiable.
• Stuck reservations — a worker crash mid-handler leaves messages reserved until timeout; define and monitor this window explicitly.
• Poison messages — no native dead-letter UI; build a requeue/purge CLI before go-live.
• Unbounded collection growth — TTL misconfiguration silently degrades Mongo performance and disk.
• Mongo availability = messaging outage — coupling queue throughput to database health means a Mongo incident now also halts async processing. Confirm this coupling is acceptable with SRE.
• Dual-runtime drift — two worker systems with different deploy, restart, and health semantics; ensure process supervision and deploys cover both.
• Schema/serialization drift — a message class change during rolling deploy can strand in-flight messages; plan for versioned message envelopes.

Ramp-up. Engineers must learn Symfony Messenger's semantics (envelope, stamps, middleware, retry strategy) on top of Laravel's queue mental model they already hold. Realistically 1–2 weeks of productive ramp for one engineer, plus the operational runbook effort. Factor that into the cost case — the license is free, the integration and ownership are not.

Bottom line for the decision record: this package solves a real problem for Symfony shops that already run Mongo, and the README is refreshingly honest about Mongo's limits as a queue. For a Laravel codebase with essentially no adoption footprint, the defensible move is to pilot it as a failure/audit transport, not as the primary queue, and only expand if the pilot demonstrates acceptable duplicate rates, reservation behavior, and Mongo load.