An acknowledgment strategy is a producer-side policy that defines when a Kafka record send counts as successful. The acks parameter trades delivery latency against confidence that the record survives on the cluster. section 3.2.3
Kafka provides three acknowledgment levels:
- acks=0 sends without waiting for the broker, giving the lowest latency but no known offset, retry, or protection when saving fails. section 3.2.3
- acks=1 waits for the leader to receive the record before follower replication completes, so leader failure can lose an apparently delivered record. section 3.2.3
- acks=all or -1 waits for replication to the in-sync followers; min.insync.replicas limits which replicas must be available. section 3.2.3
The choice is architectural rather than purely technical. Critical business data generally favors acks=all, accepting the latency and availability constraints of replicated acknowledgment. Multiple producers writing the same topic may still use different strategies. section 3.2.3 section 3.2.4
Customer 360 ODS
A Customer 360 operational data store configures the updateCustomerProfile operation with acks: all, aligning producer acknowledgment with the requirement to complete replicated processing before advancing. section 3.2.4
operations:
updateCustomerProfile:
title: Customer profile data is updated.
description: Notifies about updating the profile data.
action: send
channel:
$ref: '#/channels/customerProfile'
bindings:
kafka:
clientId:
type: string
enum: ['profile.srv']
acks: all #1
Inspect the Kafka binding that declares acks: all for the customer profile update operation. section 3.2.4
Acknowledgment alone does not settle duplicate or ordering risks. Producer idempotence combines acks=all with positive retries and max.in.flight.requests.per.connection set to 5 or fewer, using broker-managed sequence numbers to preserve partition order and prevent duplicates. section 3.2.5 section 7.4.1
