- Is micro-module/outbox-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. The repository uses Symfony DI, Doctrine ORM, and Symfony Messenger conventions, and it ships no Laravel service provider, facade, or publishable config. Treat it as a reference implementation of the transactional outbox pattern rather than a drop-in Laravel dependency.
- How do I install micro-module/outbox-bundle in a Laravel application?
- composer require micro-module/outbox-bundle will resolve as a Composer package, but it will not auto-register in Laravel because there is no service provider or package discovery support. You would need to port the Doctrine entity to an Eloquent migration, the relay to an Artisan command, and the Symfony DI wiring to a service provider and config file. For most Laravel teams the cleaner path is to copy the schema and relay design and build a first-party outbox.
- What problem does the transactional outbox pattern solve in Laravel apps?
- It avoids dual-write failures by writing domain events to an outbox table in the same database transaction as your business data, then publishing them to a broker from a separate relay worker. If the broker is down, the committed data and the event record still agree, and the relay can retry later. In Laravel this maps naturally to DB transactions, queue workers, and a scheduled Artisan relay command.
- Which Laravel and PHP versions does micro-module/outbox-bundle support?
- The package does not declare Laravel support; it targets Symfony with Doctrine ORM and Symfony Messenger, so its constraints cover PHP, Doctrine, and Messenger rather than Laravel. Check composer.json for the exact PHP and dependency matrix before assuming compatibility. In a Laravel port you control the Laravel version support, so validate against your app's PHP and database versions instead.
- What outbox table schema and indexes should I use in Laravel?
- A practical Laravel schema mirrors the package's fields: an auto-increment or UUID primary key, message_id, aggregate type and id, event type, payload, status, attempts, available_at, created_at, and published_at. Index status plus available_at for relay polling, and keep payload serialization versioned so consumers can evolve. The package's schema is the spec worth copying, but re-express it as an Eloquent migration in Laravel.
- Does the relay guarantee at-least-once delivery and how is idempotency handled?
- The README claims at-least-once delivery with idempotency support, which means consumers must deduplicate, typically by keying on message_id. Validate in the source that the outbox insert truly shares the business transaction and that publish acknowledgment happens before the row is marked sent. At-least-once is not exactly-once; duplicates are expected on retry.
- How does the package handle retries, backoff, and poison messages?
- The outbox design uses status, attempts, and available_at fields so the relay can retry failed publishes with backoff. Confirm from source, not the README, how poison messages are capped and whether a dead-letter table or queue exists. Without a clear retry cap and dead-letter path, a bad message can stall the relay or loop indefinitely.
- Can I safely use this package in production with zero stars and no release history?
- The package has zero stars, no visible dependents, no issue history, and a single maintainer, so production use means fork-and-own responsibility. Even in a Symfony shop you should audit transaction boundaries, delivery semantics, and relay failure handling before trusting it with payments or inventory events. In Laravel the risk compounds because you are also porting the framework integration.
- What are the alternatives to micro-module/outbox-bundle for Laravel teams?
- For Laravel, the realistic alternatives are a first-party outbox built with Eloquent, an Artisan relay command, and your existing queue or broker, or a port of this package's schema and relay loop. Laravel's dispatchAfterCommit and DB after-commit callbacks reduce some dual-write risk but do not replace a durable outbox when the broker can fail. Choose the outbox when you have async consumers and cross-boundary events; skip it for purely synchronous flows.
- How do I test an outbox and relay implementation in Laravel?
- Test the outbox by asserting that a business transaction rollback also rolls back the outbox row, and that a committed transaction leaves exactly one row. Simulate broker failures to verify retry counts, backoff, and dead-letter behaviour, and test consumer idempotency with duplicate message_id deliveries. The package shows no test suite in its repository signals, so plan your own coverage rather than relying on its tests.