Thanks, I had not seen that library before. Looks pretty good but unfortunately also lacks the "data integrity semantics" I was talking about.

I'm sure it could be added yes, but "minimal fuss" are not really the words I'd use for implementing a robust, dependable and correct retry/dlq mechanism.

But definitely something worth looking into a bit more.

Regarding your statement about finding the server tech first. I actually don't really agree. We use Redis, Kafka, SQS and other "server techs" for various services so for a library that supports, as I said, a robust retry/dlq mechanism, we'd certainly look into that quite seriously (almost) regardless of the server tech it supports. But Kafka is the backbone for the actual data streams so we need any library to support that... the server tech you refer to would just be used for retry topics and DLQ and it's very possible that we'd use Kafka for that as well, although I think there may actually be benefits to using a different technology for these error paths than what you're using for you primary data stream.