This is an interesting one as multiple can be used for a use case, but it's on the small details that one is more suited than the other. Depending on the use case we may need to guarantee delivery (even if duplicated) or be fine with an event not reaching
Very helpful 🙂
Thank you
An amazing write up as always. All the three can be the best solution, depending on the context.
Indeed my friend Daniel. This is the great part about system design. Everything has a place 🙂
Detailed article as always. Can't decide if I'm happy or sad about not using Kafka at work haha.
Thanks for the mention! 🙌
Thanks Akos.
I guess not needing Kafka is peaceful. And I'd prioritize peace over anything else 😅
haha nice. 😃
Simply explained, Saurabh!
I prefer asynchronous send because it balances:
- The performance benefits of a non-blocking call.
- The reliability provided by error-handling callbacks.
It allows for more fault tolerance without excessively harming the system’s throughput.
Thanks for the shoutout!
Thanks Raul.
I also prefer asynchronous send a lot over the other methods. It's a sweet spot for most scenarios.
I appreciate the mention to my article, Saurabh!
This is an interesting one as multiple can be used for a use case, but it's on the small details that one is more suited than the other. Depending on the use case we may need to guarantee delivery (even if duplicated) or be fine with an event not reaching
Thanks Fran.
Indeed the differences are in small details. Mostly, I've got away with async send though sometimes I've seen fire and forget being used as well.
awesome, thanks Saurabh. Next article on consumer side ack strategies?
Thanks Ashwani for the feedback and the topic suggestion🙂
Great explanation
Thanks Kumar Gaurav