- How do I install rossel/rossel-kafka in a Laravel application?
- Install it with composer require rossel/rossel-kafka, then publish the package configuration so that config/kafka.php exists in your application. Laravel's package discovery registers the service provider and facade, so you can resolve the Kafka client from the container without manual wiring. Before committing, check the package's composer.json: its release metadata describes it as a Symfony bundle, so confirm which integration path you are actually using.
- Which Laravel and PHP versions does rossel/rossel-kafka support?
- The overview presents it as a Laravel integration with a service provider and facade, but the package metadata (type symfony-bundle, AbstractBundle) and the 0.7 release notes describe a Symfony bundle with Symfony 6.4 support. No Laravel version matrix is published in the available material, so verify support against composer.json and the changelog for your Laravel and PHP versions. If the bundle wrapper turns out to be Symfony-only, evaluate the underlying Kafka client directly for a Laravel service.
- How do I configure brokers, SASL, and SSL in config/kafka.php?
- Connections are defined in config/kafka.php, where you declare brokers plus the producer and consumer sections. Recent versions make the broker and producer sections required, so a misconfigured container fails at build time instead of throwing an undefined array key at runtime. SSL and SASL settings are resolved lazily, and sasl_mechanism falls back to PLAIN when it is unset, so set it explicitly and verify the negotiated mechanism. Consumer-only processes never open a producer because producer creation is lazy.
- How do I publish a message to a Kafka topic in Laravel with this package?
- Resolve the Kafka client through the facade or the service container and call the publish API with a topic name and payload, using a connection defined in config/kafka.php. Producers are created lazily, so no broker connection is opened until the first publish. If your payloads need a specific wire format, plug in a custom serializer rather than encoding in your controllers.
- How do I consume Kafka messages with consumer groups and partitions?
- Use the subscribe API with a consumer group so Kafka can distribute topic partitions across your worker processes. Auto-commit is disabled and offsets are committed only after a message is processed, which protects against data loss when a worker crashes mid-batch. Run consumers as long-lived supervised processes, for example the rossel:kafka:listen command, and keep handlers idempotent because an in-flight message is redelivered after a restart.
- Can I use custom serializers or override the package's error handling?
- The package is designed to be extensible, so you can supply custom serializers and wrap the publish and subscribe APIs with your own error handling. Treat anything you cannot override as a constraint rather than an assumption. One example is failed-message handling: a failing message is logged and acknowledged rather than retried, so retry logic has to live in your consumer or a wrapper around it.
- What happens when a consumer fails to process a message, and is there a dead letter queue?
- In current releases a failing message no longer stops rossel:kafka:listen; it is logged, acknowledged, and the listener moves on to the next record. That converts a poison message from a loud partition stall into a silent drop, so alert on the EXEC_ERROR signal and own your retry path. No dead letter queue is bundled, so if you need one, publish to a DLQ or retry topic from inside your consumer or a middleware layer.
- Is rossel/rossel-kafka production ready for at-least-once delivery?
- Delivery is explicitly at-least-once: offsets commit after processing, and any message in flight at shutdown is redelivered on restart, which makes consumer idempotency a hard requirement rather than a nice-to-have. Maturity signals are thin, with a single publishing organisation, limited external battle-testing, and a bus factor of one. Pre-1.0 releases have shipped breaking changes alongside a documented migration guide, so budget maintenance time for upgrades and pin versions deliberately.
- Does rossel/rossel-kafka work with Confluent Cloud, MSK, or a non-Rossel cluster, and what are the alternatives?
- It speaks Kafka, but it is an opinionated facade over a specific broker topology, topic naming, auth, and serialization scheme, so its value drops sharply on a cluster it was not designed for. For Confluent Cloud, MSK, or any generic cluster, compare mateusjunges/laravel-kafka, enqueue transports, or ext-rdkafka used directly before adopting this one. If your consuming services are Laravel rather than Symfony, a generic client is usually the fairer comparison.
- How do I test Kafka producers and consumers in Laravel without a real broker?
- There is no documented fake or in-memory broker in the available material, so mock at a boundary you control: bind an interface or a thin publisher and consumer wrapper in the container and swap it for a spy in your test suite. Keep a small set of integration tests running against a sandbox topic with real credentials, because serialization, ACLs, and message envelope shape are where failures actually appear. A time-boxed spike with real credentials remains the only reliable feasibility check.