Symfony Messenger Laravel Package

Product Decisions This Supports

• Async work off the request path, without owning worker infrastructure. This bridge lets a PHP app push messages to SQS, SNS, or EventBridge and have Lambda consume them. That directly supports the roadmap decision "do we need a queue/worker tier at all?" — the answer can be "yes, but with no servers to patch, scale, or page someone about."
• Build vs. buy for the queue layer. The buy decision here is narrow and cheap: MIT-licensed glue code (~a few hundred lines of transport + worker wiring) instead of an engineer spending a sprint learning Bref's Lambda runtime quirks, SQS visibility timeouts, and failure/retry semantics. It is a "buy the integration, own the architecture" trade, not a platform purchase.
• Serverless migration sequencing. For teams already on Bref, this is the missing piece that makes event-driven features (order processing, webhook fan-out, image/document pipelines, notification dispatch) viable on Lambda. It unlocks "phase 2" of a Lambda migration without re-architecting the domain layer.
• Cost-model decisions on bursty workloads. Lambda-per-message pricing is attractive for spiky or low-baseline traffic and unattractive for sustained throughput. This package makes the serverless option evaluable — you can prototype and measure rather than argue hypothetically.
• Framework/interop strategy. Important scoping note: this is a Symfony Messenger bridge, not a Laravel queue driver. Laravel teams get value only if they've deliberately adopted Symfony Messenger (common in Laravel/Symfony hybrid shops, shared domain packages, or Symfony microservices alongside a Laravel app). If the org is Laravel-native, the honest PM read is "this informs a make-vs-adopt decision about the messaging abstraction itself," not "install this in the Laravel app."
• Vendor-lock-in posture. Messages go to standard AWS primitives (SQS/SNS/EventBridge) with an open-source, thin transport layer. That keeps the exit ramp to self-hosted workers or another runtime reasonably short — a useful argument when legal/architecture pushes back on serverless.

When to Consider This Package

Consider it when most of these are true:

• The team is already on Bref / AWS Lambda for PHP, or has committed to that direction. This package's value is almost entirely contingent on that.
• The application already uses Symfony Messenger (or the team is willing to adopt it as the messaging abstraction) and wants a Lambda worker transport rather than a long-running consumer.
• Workloads are bursty, low-baseline, or event-fanned-out — the shapes where per-invocation billing wins.
• Jobs complete well inside Lambda's execution limits; anything needing long-running or stateful processing belongs on ECS/Fargate or EC2 workers.
• The team accepts glue-code risk: 72 stars, zero dependents, single-org maintenance, and documentation hosted externally on bref.sh. Treat it as a maintained integration, not a supported product.
• AWS is an accepted dependency for the messaging layer; SQS/SNS/EventBridge are the target, not RabbitMQ/Kafka/Redis streams.

Look elsewhere when:

• You're Laravel-native and expect a drop-in queue driver. Laravel's queue system plus the native SQS driver covers most of this territory with far more community support. Adopting Symfony Messenger purely to use this bridge is a large architectural bet justified by other reasons.
• Throughput is sustained and high — always-on workers are usually cheaper and easier to reason about than per-invocation Lambda plus cold starts.
• You need vendor SLA, security review depth, or a large hiring pool around the messaging layer. Zero dependents means you are effectively an early adopter; budget for that.
• You require ordered, exactly-once, or long-delay semantics beyond what the underlying AWS primitives give you.
• The team has no Bref/Lambda operational experience and no appetite to build it. The package removes boilerplate, not the serverless learning curve.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) open-source adapter that lets our PHP background jobs run on AWS Lambda instead of on always-on servers. It's not a platform commitment — it's the connector between our application's messaging layer and AWS's standard queue services. The business case is cost shape (pay per job, not per idle hour) and reduced ops surface (no worker fleet to patch or scale). The risk is adoption depth: the project is young with a small user base, so we should pilot it on one non-critical workload and measure cold-start latency and cost per message before expanding.

To engineering: This is a transport bridge, not a framework. It wires Symfony Messenger to SQS/SNS/EventBridge and handles the Lambda worker loop, so we write handlers and let Bref handle the runtime. It's thin, readable, and MIT — we can fork it if needed. Caveats to plan around: it assumes Symfony Messenger, so Laravel teams need to decide whether that abstraction is worth adopting; Lambda execution limits constrain job design; and with zero dependents we're an early adopter, so pin versions, add integration tests around retry/DLQ behavior, and don't put it on a critical path in v1.