- Is emag-tech-labs/messenger-mongo-bundle a Laravel package?
- No. It is a Symfony Messenger transport that stores queued and failed messages in MongoDB. It registers itself as a Symfony bundle and expects Symfony's kernel and dependency-injection conventions. Nothing in it registers a Laravel service provider or a Laravel queue connector, so it does not plug into Illuminate\Queue.
- Can I use this MongoDB Messenger transport in a Laravel application?
- It is feasible but not a drop-in integration. You would either instantiate the transport and connection classes manually behind a custom Laravel service provider, or run Symfony's standalone Messenger worker in a separate process from php artisan queue:work. Either path is glue code your team owns and maintains, so treat it as an architecture decision rather than a configuration detail.
- How do I install and configure the Mongo transport DSN, database, and collection?
- Install with composer require emag-tech-labs/messenger-mongo-bundle, then configure a transport under framework.messenger.transports with a mongodb:// DSN. The database option is required; collection defaults to messenger_queue, queue to default, redeliver_timeout to 3600 seconds, and enable_writeConcern_majority to true. uriOptions and driverOptions map to the official MongoDB PHP library client constructor. In Laravel you would supply this configuration yourself rather than through framework config.
- Does it work with Laravel queue workers, Horizon, or queue:monitor?
- No. Laravel's queue abstraction has no awareness of Symfony\Component\Messenger, so Horizon, queue:monitor, queue:retry, the failed_jobs table, and Laravel's backoff semantics do not apply. You would run a Symfony Messenger worker instead and build your own monitoring, dashboards, and alerting from scratch.
- Which Laravel, PHP, and Symfony versions does it support, and will Composer conflict?
- The package targets Symfony Messenger and depends on mongodb/mongodb, the official PHP library, which also requires ext-mongodb. It declares no Laravel constraints, so alignment with your pinned Laravel and PHP versions must be verified, especially if you also run mongodb/laravel-mongodb. A Composer conflict there stalls the whole initiative, so pin exact versions and test the dependency graph early.
- How are retries and failed messages handled with this transport?
- Retries and failures follow Symfony Messenger's model, not Laravel's. Failed messages land in the configured failure transport and are inspected or replayed with messenger:failed:show and messenger:failed:retry. Redelivery of reserved messages is governed by redeliver_timeout. Assume at-least-once delivery with possible duplicate processing, and verify redelivery behavior empirically.
- Is MongoDB a good queue backend for high-throughput messaging?
- The README itself says MongoDB is not the best tool to be used as a queue. Consumption is polling-based with reservation-style updates and TTL cleanup, which does not match Redis, SQS, or RabbitMQ for throughput or delivery guarantees. It is reasonable for low volume, a few messages per second, with minutes-level latency tolerance; it is the wrong tool for high-throughput workloads.
- What delivery guarantees does the transport provide, and can messages be duplicated?
- Expect at-least-once delivery with possible duplicate processing. Reserved messages that are not acknowledged within redeliver_timeout, default 3600 seconds, can be picked up again. Pre-1.0 transport semantics around delayed retries and reservation timeouts should be tested in your environment rather than assumed.
- Can I use this bundle only for failed-message storage alongside an existing queue?
- Yes, and that is the README's own rationale: persistent storage for failed messages when your application already runs MongoDB. Treating it as a failure or audit transport next to an existing primary queue keeps the blast radius small and makes a low-commitment pilot possible. Colocating a queue on a primary transactional Mongo cluster is still a capacity and blast-radius concern.
- Is the package actively maintained and safe for production, and what are the alternatives?
- It is an open-sourced internal tool from eMAG Tech Labs with roughly 16 stars, no dependents, and no evidence of external production adoption, so bus factor and maintenance are real risks. The MIT license is fine and the review surface is small, but scrutiny is low, so pin versions and plan for a fork. Alternatives include a Redis or SQS-backed Laravel queue with a database failure store, or the native queue driver in mongodb/laravel-mongodb.