kafka asynchronous send not really asynchronous?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Apache Kafka, a popular distributed streaming platform, is known for its high-throughput and scalable messaging system. Kafka offers both synchronous and asynchronous sending methods for messages, with most developers assuming that asynchronous message sending significantly boosts performance by reducing the latency seen in synchronous sends. However, the notion that Kafka's asynchronous send is entirely asynchronous deserves further scrutiny.
Understanding Synchronous vs. Asynchronous Sending in Kafka
In Kafka, a producer sends messages to a broker, and from there, messages are routed to the appropriate partitions of a topic. Here’s how synchronous and asynchronous sending differ:
- Synchronous Sending: The producer waits for the broker's acknowledgment before proceeding. This method ensures message durability but at the cost of higher latency due to waiting on network responses.
- Asynchronous Sending: In theory, the producer sends messages and does not wait for any acknowledgments from the broker, thereby potentially increasing throughput and reducing latency.
Deeper Look into Kafka's Asynchronous Sending
Although labeled as "asynchronous," Kafka's producer API works in a slightly more complex manner:
- Producer Buffer: When you send a message asynchronously, it first goes into a buffer, and actual transmission occurs later, depending on buffer availability and the producer’s configurations.
- Batching: Kafka producers aggregate multiple messages into batches to improve efficiency and performance. These batches are sent asynchronously to the broker. However, this does not mean that individual messages are sent without waiting.
- Configurable Acknowledgment: The producer API allows you to configure how many acknowledgments the producer requires from broker replicas. The settings can be:
acks=0: Producer won’t wait for any acknowledgment (closest to true asynchronous behavior).acks=1: Producer waits for the leader broker to acknowledge.acks=all: Producer waits for all in-sync replicas to acknowledge.
- Callback Handlers: When you use the asynchronous send method in Kafka, you can provide a callback function that will be triggered once the acknowledgment is received or an exception occurs. This mechanism allows handling success or failure scenarios effectively but introduces potential waiting if the acknowledgments are configured.
- Potential for Back-pressure: If the broker or network is slow, or if the buffer fills up due to a high rate of message production, the producer might block or face delays, introducing back-pressure, which again decreases the asynchronicity.
Practical Considerations
In real-world applications, the configuration of Kafka's producer and network reliability play critical roles in how asynchronous the message sending process actually is. For genuinely high-throughput scenarios, developers might opt to use acks=0 to avoid waiting. However, this setting risks data loss.
Example Scenario
Consider a producer configured with acks=1 and a high throughput setting. Even though messages are sent asynchronously, the producer waits for the leader's acknowledgment, which could introduce a delay especially noticeable when network issues occur or the broker is under heavy load.
Summary Table
| Feature | Synchronous Send | Asynchronous Send | Notes |
| Acknowledgment Wait | Yes | Configurable | acks=0, acks=1, acks=all |
| Throughput | Lower | Potentially higher | Depends on ack configuration and network |
| Data Safety | Higher | Lower | acks=0 risks data loss |
| Latency | Higher | Lower | But affected by back-pressure and acks config |
| Handling Failures | Immediate reaction | Callback mechanism | Async requires proper callback handling |
| Complexity | Lower | Higher | Requires understanding of Kafka configs |
Conclusion
Kafka's asynchronous send method, while providing mechanisms to enhance throughput and reduce latency, isn't entirely free from synchronous behavior, particularly under certain configurations and scenarios. Understanding these details is crucial for optimizing Kafka deployments according to specific needs and ensuring that the system's behavior aligns with performance expectations.

