Acks, short for acknowledgements, is a setting that tells a Kafka producer how much confirmation to wait for before considering a message successfully sent.

When a producer sends a message to Kafka, that message does not simply vanish into the void, hopefully arriving somewhere useful. Kafka can send a confirmation back, an acknowledgement, once the message has actually been written. The acks setting controls exactly how much proof the producer demands before it treats that confirmation as good enough to move on.

This single setting has an outsized effect on a system’s behavior. Set it one way, and messages fly out with almost no delay, but some could silently vanish if something goes wrong at the wrong moment. Set it another way, and every message is confirmed as safely and thoroughly stored across multiple servers, at the cost of a little extra waiting time on every send.

Every messaging system faces the same unavoidable tension: confirming something took longer, but confirming nothing is dangerous.

If Kafka always waited for the strongest possible confirmation on every single message, every send would be slower than it needs to be, even for data where a rare, tiny bit of loss would barely matter, such as a mobile app logging which button a user tapped. On the other hand, if Kafka never waited for any confirmation at all, even critical data, such as a bank transaction, could occasionally vanish without a trace, with no way for anyone to even notice.

Rather than forcing one single answer on every use case, Kafka hands this decision to the people building the system. The acks setting lets a payment service demand the strongest possible guarantee, while a casual analytics pipeline, sending millions of low-stakes events, can happily trade a little certainty for a lot more speed.

A handful of closely related terms come up whenever acks is discussed. Understanding them together makes the whole picture click into place.

Kafka offers three distinct settings, each representing a different point along the speed-versus-safety spectrum.

flowchart LR
    A["acks = 0
No wait"] --> B["acks = 1
Wait for leader"]
    B --> C["acks = all
Wait for every in-sync replica"]
    A -.->|Fastest, riskiest| A
    C -.->|Slowest, safest| C
        

This is the boldest, fastest setting, and understanding exactly what it gives up is essential before ever choosing it.

With acks = 0, the moment a producer hands a message off over the network, it considers its job done. It does not pause, does not check, and does not even find out later whether the broker ever actually received it. If the network drops the message, if the broker is briefly unreachable, or if any number of small glitches occur, the message is simply gone, with no error, no retry, and no way for anyone to realize it happened.

sequenceDiagram
    participant P as Producer
    participant B as Broker
    P->>B: Send message
    Note over P: Moves on immediately,
does not wait for a reply
        

This is the balanced middle setting, and understanding its one specific weak spot is the key to using it wisely.

With acks = 1, the producer waits until the leader replica has written the message to its own local log, and only then does it consider the send successful. This protects against the most common kinds of problems, a dropped network packet, a brief connection hiccup, since the producer genuinely knows the leader has the data before moving on.

sequenceDiagram
    participant P as Producer
    participant L as Leader Broker
    participant F as Follower Broker
    P->>L: Send message
    L->>L: Write to local log
    L-->>P: Acknowledge
    Note over L,F: Follower may not have
copied the data yet
        

The gap that remains is narrow but real: if the leader crashes in the brief window right after confirming, but before any follower has managed to copy that specific message, the data is lost, even though the producer was already told the send succeeded. In everyday operation this window is extremely small, but for genuinely critical data, it is a risk worth naming plainly rather than glossing over.

This is Kafka’s strongest promise, and it is worth seeing exactly how that extra confidence is earned.

With acks = all, the leader does not confirm the write to the producer the moment it has been written locally. Instead, it waits until every currently in-sync replica, every follower that is genuinely caught up, has also confirmed receiving the same message. Only once all of them agree does the leader finally tell the producer the send was successful.

sequenceDiagram
    participant P as Producer
    participant L as Leader Broker
    participant F1 as Follower 1
    participant F2 as Follower 2
    P->>L: Send message
    L->>L: Write to local log
    L->>F1: Replicate message
    L->>F2: Replicate message
    F1-->>L: Confirm received
    F2-->>L: Confirm received
    L-->>P: Acknowledge only after both confirm
        

This means that even if the broker holding the leader replica fails the very instant after confirming, the message still exists safely on at least one other server, ready to be promoted as the new leader without any data loss. This is why acks = all is the standard choice for data where loss is simply not acceptable.

With each setting explained individually, seeing them laid out together makes the trade-offs much easier to weigh.

Acks does not work alone. Its real strength depends entirely on how many replicas actually exist to confirm a write.

Acks = all is only as strong as the number of in-sync replicas available to confirm it. If a topic is configured with a replication factor of 1, meaning there is only ever one copy of the data, then acks = all behaves almost identically to acks = 1, since there is no follower to wait for in the first place. The real protection of acks = all only shows up when it is paired with a genuinely healthy replication factor, commonly 3, giving it multiple independent copies to actually confirm against.

A closely related setting decides exactly how many in-sync replicas must exist before Kafka will even accept a write under acks = all.

Kafka has a companion setting, often called the minimum in-sync replicas requirement, that specifies the smallest number of replicas that must be in sync for a write using acks = all to be accepted at all. If too many followers have fallen behind or gone offline, and the number of healthy in-sync replicas drops below this minimum, Kafka will actually refuse to accept new writes for that partition, rather than silently weakening its promise.

The choice of acks shows up as a deliberate, considered decision across nearly every serious Kafka deployment.

Every acks setting brings real, honest advantages, and every one of them asks something in return.

Acks itself is not primarily a security setting, but it interacts with security-relevant guarantees in ways worth understanding.

The acks setting is invisible in normal operation, but its effects show up clearly in a handful of production metrics.

A few consistent habits separate teams who use acks deliberately from teams who get quietly surprised by it later.

Helpful patterns

• Matching acks to data importance — choosing the setting deliberately based on what actual harm a lost message would cause.
• Pairing acks = all with a healthy replication factor — so the guarantee has real backups to actually rely on.
• Setting a minimum in-sync replicas requirement — turning acks = all into an enforced floor rather than a hopeful best effort.
• Documenting the choice per topic — so future engineers understand exactly why a particular topic uses a particular setting.

A short checklist for choosing and configuring acks with confidence.

Modern Kafka producer defaults commonly use acks = all, reflecting a general industry shift toward favoring safety over raw speed unless a team deliberately chooses otherwise.

For many typical use cases, yes, it offers a sensible balance. But for anything where even a rare loss would cause real harm, acks = all is the safer choice.

No, acks and duplicate prevention are separate concerns. Acks controls how confirmed a write is; preventing duplicates from retries is handled by a related feature called idempotent production.

Yes, acks is set by the producer for each send, so different applications or topics can easily use whatever setting fits their own data’s importance.

For extremely high-volume, low-stakes data where speed matters far more than occasional, harmless gaps, such as certain kinds of debug logging or non-critical telemetry.

It makes data loss extremely unlikely under realistic failure scenarios, as long as it is paired with a healthy replication factor, but no distributed system can offer an absolute, mathematical guarantee against every conceivable disaster.

We started with a simple courier drop-off and ended with one of the most consequential settings in all of Kafka. Acks decides exactly how much confirmation a producer waits for before considering a message safely written, ranging from no confirmation at all, to confirmation from just the leader, to confirmation from every in-sync replica. This one choice, repeated across every topic in a system, shapes how much speed a team enjoys and how much certainty they can honestly promise their users. Choosing acks thoughtfully, and pairing it with a sensible replication factor, is one of the clearest, most direct ways to decide exactly how much a system is allowed to forget.