What Differs from Kafka
Understand the KubeMQ Kafka behaviors that need attention before moving a production workload from Apache Kafka.
KubeMQ accepts standard Kafka clients, but three behaviors need an explicit check before a production migration.
Delivery acknowledgements
On a multi-node deployment, use acks=1 or acks=all. An acks=0 produce sent to a follower is not forwarded to the leader and is dropped without a response. A single-node deployment has no follower, so this case does not apply. See Durability and retention.
Retention limits
retention.ms can evict records when it is set to a finite positive value. retention.bytes is accepted and returned by the API, but it does not enforce a size limit. Set a time retention limit and monitor storage until size-based retention is available. See Durability and retention.
Keyed partitioning
The Kafka client chooses the partition for a keyed record. Java and franz-go use a murmur2-based hash by default, while librdkafka-based clients such as kcat and confluent-kafka use CRC32. The same key can therefore land on different partitions when producer libraries differ. Use one partitioning strategy for a topic that depends on per-key ordering. See Partitions and ordering.
Was this page helpful?
Durability & Retention
How Kafka durability maps to KubeMQ — the acks 0/1/all contract, quorum-fsynced zero-acked-loss, retention by time and size, and log compaction.
Getting Started
Start kubemq-server, then produce and consume your first message over the Kafka wire protocol with kcat and seven client libraries — a full round-trip.