Kafka Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for event streaming. This package is best treated as prior art, not a dependency. It encodes one team's opinionated answer to the recurring questions — how to wire producers/consumers, where serialization lives, how topics are named, how consumer loops and offsets are handled. That makes it a useful input to an architecture decision record (ADR) even if we never install it.
• Whether Kafka belongs in the roadmap at all. The package only pays off if we have a genuine streaming need — cross-service event bus, audit/activity log fan-out, data-lake or warehouse ingestion, CDC from the primary database, replayable event history. If our needs are "run a job later," Laravel's queue + Redis/SQS is cheaper and already staffed. Kafka buys ordering, retention, and multi-consumer replay; it costs a broker fleet, Schema Registry, and on-call surface.
• Roadmap sequencing: async foundation vs. feature work. Adopting any Kafka client forces upstream decisions (topic taxonomy, event schema/versioning, idempotency keys, dead-letter handling, local dev story). Those are quarter-level commitments, not a sprint task. This assessment should gate the roadmap item, not just the library choice.
• Vendor and dependency risk posture. Archived, 2 stars, 0 dependents, last release January 2023 — this fails every ecosystem-health gate we would apply to a production dependency. The decision it supports is explicit: do not adopt; if the pattern is valuable, fork and own it, and budget the maintenance line item accordingly.
• Framework fit. It is a Symfony bundle. We are a Laravel shop. Laravel reuses Symfony components internally, but bundle service-provider wiring, configuration trees, and autoconfiguration do not map onto Laravel's container, config, and queue/event systems. The integration cost is real and the payoff is a package nobody maintains.

When to Consider This Package

Consider it (as a reference, not a dependency) when:

• We are scoping a Kafka integration and want a concrete, opinionated baseline to react to — topic naming, serde boundaries, consumer lifecycle, error handling — before writing our own ADR.
• A team is already on Symfony, pinned to the Symfony/PHP versions this bundle supported in early 2023, needs a throwaway prototype this week, and is prepared to vendor the code into the repo and own it.
• We want a cautionary comparison point when evaluating maintained alternatives (Confluent's PHP client with Schema Registry, enqueue/rdkafka, or mature Laravel Kafka packages) — "what does a bundle-shaped solution look like, and what did this one get right?"

Look elsewhere when (all of which apply to us today):

• The app is Laravel, not Symfony. Framework mismatch means custom glue, not integration.
• We need PHP 8.2+/Laravel 10+ compatibility. A 2023-era archived bundle will fight the dependency resolver and will not track framework upgrades.
• We need security patching, CVE response, or any support expectation. Archived means zero. That is a hard stop for regulated or customer-facing data paths.
• We need capabilities beyond a basic producer/consumer loop — Schema Registry/Avro/Protobuf, exactly-once semantics, transactional producers, consumer-lag observability, DLQ tooling, distributed tracing.
• We need ecosystem validation. 2 stars and 0 dependents means no battle-testing, no community answers, and no second data point when it breaks at 3 a.m.
• Local development and CI matter. No maintained image/config story means we build the docker-compose, test harness, and contract tests ourselves anyway.

How to Pitch It (Stakeholders)

To executives: We evaluated a community package for connecting our platform to Apache Kafka. It is well-intentioned but effectively abandoned — no release since January 2023, no dependents, and it targets Symfony rather than our Laravel stack. Recommendation: do not adopt it. We should still make the underlying decision consciously: if we are committing to real-time event streaming on the roadmap, we fund it as a platform capability with a maintained client, schema governance, and on-call ownership; if our needs are background job processing, we stay on the queue infrastructure we already run and spend nothing. Either way this package is not the cost driver — the operational commitment is, and that is the number worth deciding on.

To engineering: Treat this as a design reference only. It gives us a worked example of opinionated Kafka wiring — useful raw material for our own ADR on topic conventions, serialization boundaries, consumer lifecycle, idempotency, and dead-letter handling. Do not add it to composer.json: archived upstream, zero dependents, pre-2024 Symfony constraints, and a framework mismatch with Laravel. Proposed next step is a one-week timeboxed spike: extract the patterns worth keeping, benchmark against a maintained client, produce the ADR, and return with a build-vs-buy recommendation and an honest estimate of the ongoing maintenance cost — because whichever path we choose, we own that code.