Message Outbox For Illuminate Laravel Package

Product Decisions This Supports

• Reliability-critical flows: Any user-visible outcome where "database commit succeeded but the event was lost" is a defect — order placed but fulfillment never notified, payment captured but ledger never updated, account created but welcome email never sent. The transactional outbox converts silent loss into guaranteed at-least-once delivery.
• Roadmap enablement: Partner webhooks, fulfillment/payment integrations, warehouse feeds, search index sync, and cross-service cache invalidation can ship without distributed transactions or 2PC. This unblocks a category of features rather than a single ticket.
• Build vs. buy the pattern, not the code: The decision is "adopt the transactional outbox" versus "keep writing ad-hoc dual-write code." This package is a thin Illuminate adapter over EventSauce's outbox — small enough that "buy" mostly means adopting a proven shape and conventions, not volume of code. A competent engineer can hand-roll the equivalent in a day or two, and that is a legitimate outcome.
• Operational commitment decision: Adoption implies a relay worker (cron/supervisor/queue) that must be owned, monitored, and alerted on. That is a product-visible cost — it belongs in the roadmap and the on-call budget, not just the architecture diagram.
• Use cases in scope: Transactional notifications, downstream payment/ledger events, partner-facing webhooks, denormalized read-model/projection updates, and any integration where the consumer cannot join your database transaction.
• Contract-level guarantee: Enables a defensible promise in SLAs and commercial terms — "every confirmed order emits exactly one fulfillment event" — often worth more than the feature being protected.

When to Consider This Package

Adopt when:

• You run Laravel/Illuminate on a relational database and the message consumer is external (broker, partner endpoint, separate service) and therefore cannot participate in your transaction.
• You already have, or are willing to fund, a relay worker plus dead-letter handling and idempotent consumers. The outbox is a two-phase mechanism; without the relay it is just an extra table.
• Your team is comfortable with DDD/EventSauce idioms (Message, dispatcher, consumer interfaces) and understands this is a low-level library, not batteries-included. Expect to write the wiring, the relay loop, and the failure handling yourself.
• You want the pattern more than the package — worth adopting the shape even if you reimplement the ~200 lines.

Look elsewhere when:

• Single app, single database, consumer is your own Laravel queue. afterCommit job dispatch (or the database queue driver) covers most of this with far less machinery and no new operational surface.
• Loss is tolerable — analytics pings, debug logging, non-critical telemetry.
• You need a supported vendor dependency. Zero stars, zero dependents, and a [READ ONLY] subtree split of a monorepo are governance signals, not quality signals. Pin an exact version, assume you own the code, and budget for a fork if the split lapses or the upstream monorepo restructures.
• Your platform team standardizes on managed CDC (Debezium, EventBridge + stream, etc.) or already has an internal outbox service. Don't run two patterns for the same problem.

How to Pitch It (Stakeholders)

To executives: This is insurance against the "order placed, invoice never generated" class of bugs — the ones that surface as support tickets and reconciliation work weeks later. It lets us ship event-driven features (partner webhooks, fulfillment, ledger events) with a real guarantee: if the database commit succeeded, the event will be delivered. The library is free and tiny; the actual cost is a background relay process we must run and monitor — roughly a fraction of an engineer plus on-call attention. Recommend adopting the pattern; treat this specific package as a replaceable implementation detail.

To engineering: It's the Illuminate split of EventSauce's message outbox. It writes messages to an outbox table inside the same transaction as domain state, then relays them to a broker — eliminating the dual-write problem for any feature spanning DB + messaging. Caveats to flag up front: 0 stars, 0 dependents, read-only sub-split, single upstream maintainer, so there is no community safety net; the surface is small enough to vendor or fork if needed. It only pays off if paired with an explicit relay worker, idempotent consumers, dead-letter handling, and pruning — otherwise at-least-once degrades into duplicates plus silent failures, and an unpruned outbox degrades write performance across the whole application. Benchmark it against Laravel's afterCommit dispatch first; for internal-only consumers that is usually the right call. Before committing, get answers on declared illuminate/*/PHP constraints and Laravel 11/12 support, whether a publishable migration ships, the reference relay implementation, the concurrency/locking strategy for multi-worker relays, and the outbox retention story.

Bottom line: The architecture is right and the code surface is small, but this repository is a low-signal distribution artifact — treat the parent EventSauce project as the dependency you are really adopting, and pin, monitor, and plan to fork accordingly.