Message Broker Amqp Laravel Package

Product Decisions This Supports

Assessment basis: this package's own feature surface is not documented in the supplied data; the below is derived from the v0.3.0 release metadata and its declared dependency graph (freyr/message-broker-contracts, freyr/identity). Treat the capability claims as provisional until the package README/API surface is reviewed.

• Event-driven / asynchronous architecture: the package sits on top of freyr/message-broker-contracts, so it is the integration layer between your Laravel application and a message broker. This is the decision to move work off the request path — order fulfilment, notifications, webhook fan-out, audit/event sourcing, cross-service sync.
• Build vs buy for an internal event bus: adopting a small, opinionated contracts-plus-adapter package versus hand-rolling publisher/consumer abstractions. The buy case rests on the contracts package being shared across services; the build case rests on the fact that this is still 0.x and the abstraction may not survive to 1.0.
• Identity strategy as a product-wide standard: the freyr/identity 0.4 → 1.0 move from UUID v7 to ULID is not a local refactor. It sets the identifier format for message IDs, correlation IDs, and potentially aggregate IDs across every producer and consumer. That makes "which ID format is canonical?" a platform decision, not a library detail.
• Ecosystem/vendor consolidation: committing to the freyr/* namespace couples this package's upgrade cadence to two sibling packages. That is a roadmap input — how much of your integration surface do you want controlled by one maintainer's release train?
• CI and quality-gate posture: enabling PHPUnit failOnDeprecation signals the package treats deprecation warnings as build failures. Worth mirroring in your own pipelines if you depend on it, since upstream deprecations will otherwise surface silently in your test runs.

When to Consider This Package

Adopt when:

• You are already using freyr/message-broker-contracts or other freyr/* packages — the marginal cost of this layer is low and contract compatibility is the main integration risk anyway.
• You need a thin Laravel-native publisher/consumer abstraction over an existing broker rather than a full framework (no workflow engine, no schema registry, no dead-letter management claims here).
• Your platform has already standardised, or is willing to standardise, on ULID identifiers — or you have a migration path for stored message IDs.
• You can absorb breaking changes on a 0.x cadence. The ^0.1 → ^0.3 and ^0.4 → ^1.0 bumps in a minor release are normal pre-1.0 semver, but they confirm the public API is not yet frozen.

Look elsewhere / defer when:

• You require a stable 1.0 contract with deprecation windows. There is no evidence of one yet, and a minor version just shipped two breaking dependency bumps.
• You are pinned to UUID v7 identifiers in production. The ULID switch is a data-format change: different string representation (26-char Crockford base32 vs 36-char hyphenated hex), different sort/lexicographic properties, different DB column sizing, and different external-consumer parsing. Any persisted message IDs, logs, or downstream systems need mapping.
• Your consumers are polyglot or external. A ULID migration forces coordinated releases outside your Laravel boundary, which changes the cost calculus substantially.
• You need guarantees this package does not visibly make: delivery semantics, retry/backoff policy, ordering, schema evolution. Those likely live in the broker or the contracts package — verify before committing architecture to it.
• You are on a PHPUnit/PHP version where failOnDeprecation surfaces third-party deprecations you cannot control; this can make your build red for reasons outside your team.

Adoption gate before committing: confirm the contracts 0.3 API diff, confirm whether ULID generation/parsing is centralised in freyr/identity (preferred) or leaks into this package's call sites, and confirm whether message IDs are persisted anywhere in your estate.

How to Pitch It (Stakeholders)

For executives: This is a small integration component that lets our Laravel services publish and consume messages through a broker rather than calling each other synchronously — the architectural pattern behind faster, more resilient feature delivery. It is not yet a stable platform commitment: the newest version is 0.3.0 and ships two breaking dependency upgrades, including a change to our identifier format. Recommendation is to pilot on one non-critical event flow, not to standardise across the estate until the API reaches 1.0. Cost is low; the risk is churn, not licence or performance.

For engineering leadership: The v0.3.0 release is a coordination event masquerading as a dependency bump. The UUID v7 → ULID change affects any persisted message identifier, log correlation, or external consumer parsing; it needs a migration plan, not a composer update. freyr/message-broker-contracts 0.1 → 0.3 means producer and consumer services must move together — treat it as a single deploy unit or version the wire format. The package's own choice of failOnDeprecation is a good signal on maintenance discipline and worth copying internally, but it also means upstream deprecations can break our build through this dependency.

For the product team: No user-facing behaviour changes in this release. The planning impact is sequencing — the identifier migration touches analytics joins, support tooling, and any exported data containing message IDs, so it should be scheduled as a platform change with a freeze window rather than folded into routine dependency maintenance.