# Kafka producer acks explained

*Learn how producer acknowledgments affect data durability*

The producer acknowledgment (acks) setting is one of the most critical configurations for balancing durability, performance, and availability in Kafka. Understanding each option helps you make the right trade-offs for your use case.

**What you'll learn:**
- The three acks settings and their guarantees
- How acks interacts with replication
- Performance implications of each setting
- How to choose the right setting for your use case

## Acks overview

Kafka producers only write data to the current leader broker for a partition and have to specify an acknowledgment (`acks`) level to determine when a message is considered successfully written.

> **The default value of acks has changed with Kafka v3.0**
> - If using Kafka = v3.0, `acks=all`

![Comparison of acks=0 fire and forget, acks=1 leader-only acknowledgment, and acks=all full replication acknowledgment flows](https://www.conduktor.io/assets/kafka/diagrams/kafka-producer-acks-deep-dive.svg)

```mermaid
flowchart TB
    subgraph acks0["acks=0 (Fire and forget)"]
        P0["Producer"] -->|"Send"| B0["Leader"]
        P0 -->|"Don't wait"| Done0["Continue"]
    end

    subgraph acks1["acks=1 (Leader only)"]
        P1["Producer"] -->|"Send"| B1["Leader"]
        B1 -->|"ACK"| P1
        B1 -.->|"Replicate async"| R1["Replica"]
    end

    subgraph acksAll["acks=all (Full replication)"]
        P2["Producer"] -->|"Send"| B2["Leader"]
        B2 -->|"Replicate"| R2["Replica"]
        R2 -->|"Confirm"| B2
        B2 -->|"ACK"| P2
    end
```

## acks=0 (fire and forget)

When `acks=0`, producers consider messages "written successfully" immediately after sending, without waiting for broker acceptance.

![Kafka Producer Acks Setting set to 0](https://www.conduktor.io/assets/kafka/Adv-Producer-Acks-DD-1.png)

**Characteristics:**
- Highest possible throughput
- Lowest latency
- No durability guarantees
- Potential for data loss if broker fails

**Use cases:**
- Metrics collection where some data loss is acceptable
- High-volume logging where speed is more important than reliability
- Scenarios where losing some messages won't impact business logic

## acks=1 (leader acknowledgment)

When `acks=1`, producers consider messages "written successfully" when the leader broker acknowledges receipt.

![Kafka Producer Acks Setting set to 1](https://www.conduktor.io/assets/kafka/Adv-Producer-Acks-DD-2.png)

**Characteristics:**
- Balanced throughput and durability
- Leader response required before considering message sent
- Replication happens asynchronously in background
- Risk of data loss if leader fails before replication completes

**Use cases:**
- Most common configuration for general-purpose applications
- Good balance between performance and reliability
- Suitable when some data loss is acceptable but should be minimized

## acks=all (full acknowledgment)

When `acks=all`, producers consider messages "written successfully" when all in-sync replicas (ISR) accept the message.

![Kafka Producer Acks Setting set to all](https://www.conduktor.io/assets/kafka/Adv-Producer-Acks-DD-3.png)

**Characteristics:**
- Highest durability guarantees
- Lower throughput due to replication requirements
- Works with `min.insync.replicas` setting
- No data loss as long as at least one ISR remains

**Use cases:**
- Critical business data that cannot be lost
- Financial transactions
- Audit logs and compliance data
- Any scenario where data durability is paramount

> **Popular Configuration**
> `acks=all` and `min.insync.replicas=2` provides optimal data durability and allows withstanding the loss of one Kafka broker.

## Interaction with min.insync.replicas

The `min.insync.replicas` setting works together with `acks=all` to control durability:

| min.insync.replicas | Meaning | Broker failures tolerated (RF=3) |
|---------------------|---------|----------------------------------|
| 1 | Only leader needs to be in-sync | 2 |
| 2 | Leader + 1 follower must acknowledge | 1 (recommended) |
| 3 | Leader + 2 followers must acknowledge | 0 |

## Performance comparison

| Setting | Throughput | Latency | Durability | Data loss risk |
|---------|------------|---------|------------|----------------|
| `acks=0` | Highest | Lowest | None | High |
| `acks=1` | High | Low | Leader only | Medium |
| `acks=all` | Lower | Higher | Full ISR | Low |

## Configuration examples

### High durability (recommended for critical data)
```properties
acks=all
min.insync.replicas=2
retries=Integer.MAX_VALUE
enable.idempotence=true
```

### Balanced performance and reliability
```properties
acks=1
retries=Integer.MAX_VALUE
```

### Maximum throughput (use with caution)
```properties
acks=0
retries=0
```

Each setting has different data loss scenarios: with `acks=0`, data is lost if the producer fails to send or the broker is down; with `acks=1`, data is lost if the leader fails before replication; with `acks=all`, data is only lost if all ISRs fail simultaneously.

> **See it in practice with Conduktor**
> [Conduktor Console](https://docs.conduktor.io/guide/manage-kafka/kafka-resources/topics) lets you view topic configurations including replication factor and min.insync.replicas. Monitor ISR status to ensure your acks settings provide the intended durability guarantees.

## Next steps

- [Configure producer retries](https://www.conduktor.io/kafka/kafka-producer-retries) to recover from transient failures
- [Enable idempotent producers](https://www.conduktor.io/kafka/idempotent-kafka-producer) for exactly-once semantics
- [Optimize producer batching](https://www.conduktor.io/kafka/kafka-producer-batching) for throughput