Questions
1 of 5
Basics
Cluster Architecture
Topics, Partitions and Records
Producers
Consumers
Consumer Groups
Offset Management
Replication and Fault Tolerance
Storage Internals
Networking and Request Processing
Performance and Throughput
Delivery Semantics
Transactions
Kafka Streams
Kafka Connect
Schema and Serialization
Security
Error Handling and Retry Patterns
Ordering and Partitioning Design
Testing
Monitoring and Observability
Debugging and Troubleshooting
Deployment and Operations
Admin and CLI Operations
Reliability and Disaster Recovery
Integration Patterns
Modern Kafka Architecture
Advanced Internals
Scalability and Capacity Planning
Architecture and System Design
Production Best Practices
Expert Edge Cases
Versioning and Upgrades
Admin and CLI Operations
Senior End-to-End Scenarios
Difficulty: 2/10
Reliability and performance
acks controls how many brokers must confirm a write before the producer treats it as successful, trading durability against latency
The acks setting defines when the broker's response counts as success for a produce request. With acks=0 the producer does not wait at all: it is fastest, but a lost record is invisible and you never learn the offset. With acks=1 the partition leader acknowledges after writing to its own log. If the leader dies before followers copy the record, that acknowledged record can be lost. With acks=all (or -1) the leader waits until all replicas currently in the in-sync replica set (ISR) have the record. This is the setting that gives real durability, but it adds replication round-trip time to every request.
The part people miss is that acks=all alone is not a guarantee. It means all replicas in the ISR, and the ISR can shrink to just the leader. If min.insync.replicas is 1, acks=all degrades to leader-only durability. The standard durable combination is replication.factor=3, min.insync.replicas=2 and acks=all: a write needs the leader plus at least one follower, and if fewer than two replicas are in sync the producer gets NotEnoughReplicas errors instead of silently accepting risky writes. The cost is availability: with two of three brokers down, writes stop. That is a deliberate trade of availability for consistency.
javascript
- 1
Trade-off: acks=1 is lower latency and reasonable for metrics, logs or clickstream where losing a few records on failover is acceptable. acks=0 fits only fire-and-forget telemetry. I use acks=all for anything that represents business state.
- 2
Common mistake: believing acks=all means all replicas. It means all in-sync replicas, so min.insync.replicas is what sets the floor.
- 3
Common mistake: tuning acks without considering retries. With acks=0 the producer cannot detect failures, so retries do nothing for you.
- 4
Latency note: acks=all latency is driven by the slowest in-sync follower, so one slow broker or disk raises p99 for everyone, and cross-AZ replication adds network time.
- 5
Version note: client defaults changed in Kafka 3.0, where acks=all and idempotence became defaults. Older clients default to acks=1, so state the version and set it explicitly in production code.
Scenario Questions
0-2 years experience
2-5 years experience
- 1A topic has replication factor 3, min.insync.replicas=1 and producers use acks=all. A leader crashes right after acknowledging. Can data be lost? Walk through the sequence.
- 2Producers start receiving NotEnoughReplicas errors after a broker failure. What does that tell you about the topic configuration, and what are your options in the incident?
5-8 years experience
- 1p99 produce latency with acks=all doubled after a rollout, but broker CPU is flat. Which replication-related causes would you check first and how?
- 2The business wants zero acknowledged-write loss and also 99.99 percent write availability during a single AZ outage. How do replication factor, min.insync.replicas and acks interact, and what can you honestly promise?
8+ years experience
- 1You are writing the platform's standard producer profiles (critical, standard, best-effort). Which acks, min.insync.replicas and related settings go in each, and how do you stop teams from silently overriding them?
- 2A stretched cluster spans two regions with a witness. How does the choice of acks and min.insync.replicas change durability and latency when a region is lost?