Messenger Kafka Laravel Package

Product Decisions This Supports

• Feature velocity on async / event-driven work. Any roadmap item that depends on durable, replayable, multi-consumer event delivery — order lifecycle events, webhook fan-out, notification pipelines, activity feeds, audit trails, search-index hydration, analytics ingestion — can be built against the org's existing Kafka backbone instead of custom cron/queue plumbing.
• Build vs. buy on transport layer. A hand-rolled Kafka transport (producer/consumer wiring, serializer, worker loop, retry + dead-letter handling, error surfacing) is realistically 1–3 engineer-weeks of initial build plus ongoing maintenance. This package is a credible "assemble, don't build" starting point that converts that estimate into days of integration and review.
• Queue modernization roadmap. Supports a phased migration off database/Redis queues: (1) mirror events to Kafka read-only, (2) dual-write with consumers in shadow mode, (3) Kafka as the system of record for cross-service events. Each phase is independently shippable and reversible.
• Architecture hedge via abstraction. Adopting Symfony Messenger as an in-app abstraction (with this Kafka transport behind it) means the transport becomes swappable — Kafka today, AMQP/SQS/Redis later — without rewriting handler code. That is a decision about future option value, not about Kafka.
• Cross-language interoperability. Enables PHP services to publish domain events that Java/Go/Python teams consume, and to consume platform events they already produce — often the single blocking gap to joining a shared event platform.
• Explicit non-decisions. This package does not decide whether to run Kafka (brokers, ops, cost, monitoring). It does not decide schema contracts, serialization format, or governance. Those remain separate, higher-stakes decisions and should not be conflated with the transport choice.
• Opportunity signal. High opportunity score against low adoption (92 stars, 0 dependents) suggests an underserved niche: teams that have Kafka and PHP but no well-trodden path between them. Being an early adopter is a calculated bet, not a safe default.

When to Consider This Package

Adopt when:

• Kafka is already operated in-house (brokers, ACLs, monitoring, on-call) and PHP is the application runtime that needs to participate.
• You want a thin transport: publish a message, consume a message, get out of the way. No framework ambitions.
• Symfony Messenger is already in use, or the team accepts adding it. This is the sharpest caveat for a Laravel codebase — Messenger is a second messaging abstraction layered beside Laravel's native queue/bus, and that duplication has real cognitive and maintenance cost.
• Throughput and semantics needs are modest: at-least-once delivery, manual offset/retry/DLQ policy, no distributed transactions.
• You are prepared to own supply-chain risk: single maintainer, zero dependents, MIT license. Mitigation is fork-readiness, pinning, and a vendored copy if the project goes quiet.

Look elsewhere when:

• You need schema registry / Avro / Protobuf contracts, exactly-once semantics, transactional producers, or fine-grained consumer-group rebalance control. Use the Confluent PHP client or php-rdkafka directly and accept the extra wiring.
• The codebase is Laravel-first and framework idiom matters more than transport purity. A Laravel-native Kafka package, or php-rdkafka behind a small internal adapter, will be lower friction than importing Messenger.
• The integration problem is really data capture, not messaging — CDC via Debezium + Kafka Connect avoids hand-written producers entirely.
• You need stream processing (Kafka Streams / ksqlDB semantics). PHP is the wrong runtime for that; publish to Kafka and process in a JVM/Python service.
• Event volume is low and durability/replay isn't required. SQS or Redis queues are cheaper to operate; Kafka's overhead isn't justified by "we might need it later."
• The team has no Kafka operational experience and no managed-service budget. The package isn't the risk here — running brokers is.

How to Pitch It (Stakeholders)

To executives — one paragraph:

Our PHP services can't currently participate in the event platform the rest of engineering has standardized on, which forces us into bespoke integrations and duplicated data pipelines. This is a small, MIT-licensed adapter that closes that gap at roughly days of integration effort instead of weeks of custom build. It's cheap optionality: we wrap it behind our own interface so it stays replaceable, and it commits us to nothing about Kafka itself. The tradeoff is maturity — the project has a single maintainer and effectively no downstream users — so we treat it as a fork-ready component rather than a vendor dependency.

To engineering leads — the practical read:

• It does one job: map a Messenger message onto a Kafka topic with a partition key, and run a consumer worker. Serialization, retries, DLQ, and offset policy are ours to own, not the package's.
• It is not Laravel-native. Budget for the Messenger abstraction layer explicitly; if that's a poor fit, stop here and evaluate a Laravel-targeted client instead.
• Bus factor is 1. Pin the version, keep a fork, and add an integration test suite against a real broker (Testcontainers or CI-managed Kafka) so we can validate any fork or replacement.
• Make the transport swappable behind an internal interface from day one; that single design choice defuses most of the adoption risk.

Success criteria to commit to up front: consumer lag monitored and alerting, a documented DLQ and replay runbook, p99 publish latency within the existing queue SLO, and zero handler code aware of Kafka specifics. If those aren't achievable cheaply, the decision was really "adopt Kafka more deeply," and should be re-scoped as such rather than smuggled in as a library choice.