# What Differs from Kafka (/connectors/kafka/concepts/differences-from-kafka)



KubeMQ accepts standard Kafka clients, but three behaviors need an explicit check before a production migration.

## Delivery acknowledgements [#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](/connectors/kafka/concepts/durability-and-retention#the-acks-contract).

## Retention limits [#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](/connectors/kafka/concepts/durability-and-retention#retention-time-and-size).

## Keyed partitioning [#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](/connectors/kafka/concepts/partitions-and-ordering#client-side-key-hashing).