Acknowledgment modes (acks=0, 1, all) in Kafka - Time & Space Complexity
When sending messages in Kafka, the acknowledgment mode controls how many confirmations the producer waits for before continuing.
We want to understand how the time to send messages changes with different acknowledgment settings.
Analyze the time complexity of sending messages with different acknowledgment modes.
producer.send(record, new Callback() {
public void onCompletion(RecordMetadata metadata, Exception e) {
if (e != null) {
// handle error
}
}
});
// acks can be set to 0, 1, or all in producer config
This code sends a message and waits for acknowledgments based on the configured mode.
Look at what happens each time a message is sent.
- Primary operation: Sending a message and waiting for acknowledgments.
- How many times: Once per message sent.
As the number of messages (n) grows, the time to send all messages depends on the acknowledgment mode.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 sends, each with minimal to moderate wait |
| 100 | 100 sends, each with minimal to moderate wait |
| 1000 | 1000 sends, each with minimal to moderate wait |
Pattern observation: The total time grows roughly linearly with the number of messages, but the wait time per message varies by acknowledgment mode.
Time Complexity: O(n)
This means the time to send messages grows directly with how many messages you send, regardless of acknowledgment mode.
[X] Wrong: "Using acks=0 means sending messages is instant and time doesn't grow with more messages."
[OK] Correct: Even with acks=0, sending each message takes some time, so total time still grows with the number of messages.
Understanding how acknowledgment modes affect message sending time helps you explain trade-offs between speed and reliability in real systems.
What if we batch multiple messages together before sending? How would that affect the time complexity?
Practice
acks mode in Kafka provides the fastest message sending but with the least safety?Solution
Step 1: Understand
This mode means the producer does not wait for any acknowledgment from the broker, so it sends messages fastest but with no guarantee of delivery.acks=0behaviorStep 2: Compare with other modes
acks=1waits for leader confirmation, andacks=allwaits for all replicas, both slower but safer.Final Answer:
acks=0-> Option AQuick Check:
Fastest but least safe = acks=0 [OK]
- Confusing acks=0 with acks=1
- Thinking acks=all is fastest
- Assuming acks=0 waits for leader
Solution
Step 1: Recall correct property name and value
The property isacks(plural), and to wait for all replicas, the value isall.Step 2: Check options for syntax correctness
"acks=all" uses correct key and value: "acks=all". "ack=all" has a typo "ack" instead of "acks".Final Answer:
"acks=all" -> Option CQuick Check:
Wait for all replicas = acks=all [OK]
- Using 'ack' instead of 'acks'
- Confusing 'acks=1' with 'acks=all'
- Setting 'acks=0' for all replicas
props.put("acks", "1");
producer.send(record);
System.out.println("Message sent");What does
acks=1 guarantee before printing "Message sent"?Solution
Step 1: Understand
This mode waits for the leader broker to confirm the message is received and written to its log.acks=1meaningStep 2: Compare with other options
acks=0gives no guarantee,acks=allwaits for all replicas, and producer buffer storage is unrelated.Final Answer:
Leader broker has confirmed the message -> Option DQuick Check:
acks=1 means leader confirmation [OK]
- Thinking acks=1 waits for all replicas
- Assuming no guarantee with acks=1
- Confusing producer buffer with broker confirmation
props.put("acks", "alll");What is the problem with this configuration?
Solution
Step 1: Check the value spelling
The correct value for waiting all replicas is "all", but here it is misspelled as "alll" with an extra 'l'.Step 2: Verify key and value types
The key "acks" is correct and the value should be a string. So the problem is only the typo in the value.Final Answer:
Typo in the value; should be "all" -> Option AQuick Check:
Value must be "all", not "alll" [OK]
- Assuming 'alll' is valid
- Changing key to 'ack' instead of 'acks'
- Using integer instead of string for acks
acks setting should you use and why?Solution
Step 1: Identify safety vs speed tradeoff
acks=allwaits for all replicas to confirm, ensuring maximum data safety but slower performance.Step 2: Evaluate other options
acks=0is fastest but unsafe,acks=1waits only for leader, andacks=-1is invalid or equivalent toacks=allbut less clear.Final Answer:
acks=allbecause it waits for all replicas -> Option BQuick Check:
Max safety = acks=all [OK]
- Choosing acks=0 for safety
- Confusing acks=-1 as disabling acknowledgments
- Thinking leader confirmation is max safety
Ready to prove it?
Pass the test and this pattern moves unknown
