Should You Fire and Forget an Event?
Example scenarios with Kafka
“What should we do after publishing an event?”
This question came up during the design discussion for a new project our team was working on.
There were two different points of view:
One side felt we should just forget about the event after publishing it to the Kafka broker.
The second side argued that this would reduce the quality of our solution in case something goes wrong. They suggested that we should make sure to get a confirmation that the broker received the event message.
The problem, of course, was a game of trade-offs based on the requirements of the application.
It turned out that there were 3 options we could choose from:
Fire and Forget
Synchronous Send
Asynchronous Send
1 - Fire and Forget
In this approach, we send a message to the broker and forget about it.
There’s no acknowledgment. We don’t even wait for it.
Kafka is highly available so there is a good chance that the messages are delivered without any issues. However, you can’t completely rule out lost messages.
2 - Synchronous Send
I know that synchronous sends sound dubious.
What’s the point of using an event-driven approach when you have to make things synchronous?
But Kafka does let you send messages synchronously.
In this case, the Producer waits for an acknowledgment in the form of a Future object. If there’s an exception, the Producer throws an exception.
3 - Asynchronous Send
In this approach, the Kafka Producer sends a message to the broker and continues processing other messages without waiting for an acknowledgment.
Instead, it registers a callback function.
This callback gets triggered when the Kafka broker acknowledges the message.
What did we choose?
As far as the decisions for our project were considered, we made them based on the business criticality of a particular type of event.
On a high level, the below points guided us in making the decision:
Asynchronous send is a mix of high performance and exception handling. It was ideal for business-critical events in a production scenario. The acknowledgment functionality made sure that the message was delivered to the broker without stopping the overall processing of the application.
Synchronous send sounds safe, but results in poor performance because it creates a blocking thread. We avoided this approach.
Fire and Forget is best for performance and throughput, making it suitable for cases where message delivery is not critical. We used it for functionalities like logging and user-tracking events that weren’t super-important.
So - which approach would you prefer the most when dealing with events? Also, what factors do you consider before making the choice?
Eraser Professional Plan Free Trial (Affiliate)
As you all know, I use the Eraser for drawing all the diagrams in this newsletter.
Eraser is a fantastic tool that you can use as an all-in-one markdown editor, collaborative canvas, and diagram-as-code builder.
And now you can get one month free on their Professional Plan or a $12 discount if you go for the annual plan. The Professional Plan contains some amazing features like unlimited AI diagrams, unlimited files, PDF exports, and many more.
Head over to Eraser and at the time of checkout, use the promo code “CODEX” to get this offer now.
Shoutout
Poor Communication Blocking Promo? You need these tips by
Payments 101: Stripe's Protocol by
Timeless skills in Software Development by
That’s it for today! ☀️
Enjoyed this issue of the newsletter?
Share with your friends and colleagues.
See you later with another value-packed edition — Saurabh
Solid newsletter post my friend. We go for async a lot time by using Azure Service Buses.
Simply explained, Saurabh!