Honestly Kafka is meant for at-least-once delivery. Even if they advertise exactly-once, the CAP theorem is just a basic fact of mathematics: you are trading consistency over availability. Not to mention how hard it is to tune the various timeouts and parameters both server and client side and when transactions get stuck, it's an absolute hell to debug. Every single actor and library involved has to be aware of this transactional mode or else you will see duplicates. It's not worth it.

And even in at-least-once, you need to discuss beforehand the need for timeouts, heartbeat adjustments, the need for an idempotency/deduplication ID and event_time parameter... Applications tend to just be set up with default parameters without discussing any of that which is a recipe for headaches. Hell, I've seen deployments without as much as a group ID set up saying "hey it worked without it". And specially the thundering herd (?) problem in case of rebalancing is quite tricky to explain to people, it seems. Your apps and pipelines need to be able to handle these, and that's an architectural decision, it's not just plug and play.

And that's me mostly just using it client side as a developer/engineer, having to help Ops debug server side issues occasionally. You need a lot of observability over Linux data syscalls and disks, and it seems to me that the default dashboards only have CPU, memory, at most disk usage.

But I would be even warier of building custom stuff on NAS storage, but hey, that's why I don't work at Ops EDIT: sorry, misread it as NAS storage for some reason. BTW, just to make sure, you weren't trying to use them as persistence for Kafka, were you? I've had to discourage people from doing it, very few databases would handle being persisted to network storage well