- How do I install micro-module/event-queue in a Laravel application?
- Install it with Composer using composer require micro-module/event-queue. Laravel package auto-discovery should register the service provider automatically, and if a config file ships with it you can publish it with php artisan vendor:publish. Before committing, check the composer.json constraints for the illuminate/support and php versions to confirm they match your app.
- Which Laravel and PHP versions does micro-module/event-queue support?
- The package overview does not publish an explicit support matrix, so read the illuminate/support and php constraints in its composer.json first. Confirm the package is actually exercised on your target version by running it in a sandbox against Laravel 10, 11, or 12 as needed. Pin exact versions in composer.json because an early-stage package can change requirements between minor releases.
- What does micro-module/event-queue add over Laravel's Event::dispatch and ShouldQueue listeners?
- Laravel's native Event::dispatch with ShouldQueue listeners already defers handling to the queue, so the delta needs to be articulated in one sentence before adopting this package. The advertised value is module-scoped queues, per-event retry and backoff configuration, and clean producer/subscriber boundaries across micro-modules. If those are not requirements for your app, native queued listeners cover the same ground with zero third-party surface.
- How does micro-module/event-queue guarantee at-least-once delivery?
- The package advertises at-least-once delivery, which means a consumer may receive the same event more than once, so every handler should be idempotent and deduplicate on an event ID. It does not claim exactly-once semantics. Also verify whether a transactional outbox exists, because if the database commit succeeds and the queue push fails, events can be silently lost without one.
- Which queue drivers work with micro-module/event-queue: database, Redis, or SQS?
- Because the package is described as leveraging Laravel's queue system, it should inherit whatever driver you already configure, whether that is database, Redis, or SQS. That inheritance is not the same as being tested on each driver, so confirm which drivers are exercised in CI or verify them yourself in a sandbox. A bespoke transport or table would add operational burden and should be treated as a red flag during evaluation.
- How do retries and backoff work when an event listener fails?
- The package supports configurable attempts with per-event backoff, so you can tune retry behavior by event type. Once attempts are exhausted, the job should land in Laravel's failed_jobs table where you can monitor and replay it. Align retry counts with how idempotent your downstream module handlers actually are.
- How do I keep events processed in order per module?
- Ordered processing relies on routing a module's events to a dedicated queue and running a single worker against it, since parallel workers break sequence. The package advertises per-module queues that preserve event order, but you should test this under concurrency before relying on it. If strict ordering is critical, document the worker topology as part of your deployment runbook.
- How do I publish an event from one module and subscribe to it in another module?
- Producers dispatch a domain event without importing any subscriber code, and subscribers register inside their own module through the package, keeping boundaries clean. Keep event classes in a shared contracts namespace or package and version them so a consumer upgrade does not break producers. Be careful when putting Eloquent models on the queue, since serialized attributes can break across deploys and may leak sensitive fields.
- How do I test queued events with micro-module/event-queue?
- Use Laravel's Queue::fake or the package's equivalent to assert that events were queued rather than handled inline. Test the subscriber handlers directly, including duplicate delivery and failure paths, and add at least one integration test against your real queue driver. Without published CI evidence from the maintainer, your own test suite is the only proof of correctness you will have.
- Is micro-module/event-queue production ready and actively maintained?
- Treat it as unvetted: it has zero stars and zero dependents, so there is no external evidence of production use and no community to surface bugs. Pin exact versions, read the changelog on every upgrade, and budget a fork-and-vendor contingency from day one in case the maintainer stops publishing. If that risk is unacceptable, Laravel's native ShouldQueue listeners or a dedicated transactional outbox package are the safer alternatives.