> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streamnative.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuring Kafka Producer

An Apache Kafka producer is a client application that publishes (sends) messages to StreamNative Cloud. This section gives an overview of the Kafka producer and an introduction to the configuration settings for Producers.

## Producer Configuration

The following sections describe the key configuration settings for Kafka producers and explain how they affect producer behavior.

For common client settings, such as networking and authentication settings, see [Configuring Kafka Clients](/cloud/build/kafka-clients/config/config-kafka-client).

### Message Durability

#### `acks`

Controls the durability of messages written to StreamNative Cloud. This setting has three possible values:

* `all` (default): Provides the strongest durability guarantee. The broker will wait for the message to be successfully persisted to the storage layer (either BookKeeper or object storage) before sending an acknowledgment response.

* `1`: Requires acknowledgement only from the owner broker. Provides moderate durability with better performance than `all`.

* `0`: Provides no durability guarantees but maximum throughput. The broker does not send any response, so you cannot verify message delivery or determine message offsets.

For C/C++, Python, Go and .NET clients, this is configured per-topic. To apply globally, use:

* C/C++: `default_topic_conf` sub-configuration
* Python, Go, .NET: `default.topic.config` sub-configuration

### Message Ordering

By default, messages are written to the broker in the same order that they are received by the producer client. However, certain configuration settings can affect this ordering.

#### `retries`

This setting controls message retry attempts when a send fails. When set to a value greater than `0`, retries are enabled (the default is `0`, which disables retries). With retries enabled, message re-ordering can occur if a retry succeeds after subsequent messages have already been written successfully.

#### `max.in.flight.requests.per.connection`

To maintain strict message ordering while using retries, set this value to `1`. This ensures only one request can be sent to the broker at a time, preventing any potential re-ordering. Note that when retries are disabled, the broker preserves the order of writes it receives, but failed sends can create gaps in the message sequence.

### Batching and Compression

Kafka producers attempt to collect sent messages into batches to improve throughput and efficiency.

Use the following settings to control batching and compression:

#### `batch.size`

Controls the maximum size in bytes of each message batch for the Java client. When a batch reaches this size, it is sent to the broker.

#### `linger.ms`

Use this setting to control how long the producer waits to allow more messages to accumulate in a batch before sending it. A longer linger time increases the likelihood of filling batches but adds latency.

#### `compression.type`

Enable compression with this setting. Compression covers full message batches, so larger batches typically achieve higher compression ratios. When using Snappy compression, you need write access to the `/tmp` directory. If you don't have write access to the `/tmp` directory because it's set to `noexec`, you can specify an alternate directory path that you have write access to:

```
-Dorg.xerial.snappy.tempdir=<path>
```

#### `batch.num.messages`

Use this setting with the C/C++, Python, Go, and .NET clients to set a limit on the number of messages contained in each batch.

### Queuing Limit

#### `buffer.memory`

Controls the total memory available to the Java client for collecting unsent messages. When this limit is reached, the producer will block additional sends for up to `max.block.ms` before raising an exception.

#### `request.timeout.ms`

Sets a timeout to prevent records from being queued indefinitely. If this timeout expires before a message is successfully sent, the message will be removed from the queue and an exception will be thrown. The C/C++, Python, Go, and .NET clients have similar settings.