message queue durability. when is it non-negotiable?

hey folks, i'm wrestling with a common challenge in distributed systems: message queue durability. we're building a new service that relies on event-driven communication. for most events, we're happy with at-least-once delivery and can handle duplicates. however, there are a couple of critical event types, think financial transactions, where losing a message is absolutely not an option. what are your go-to strategies and considerations when strict message durability is a must? are you always reaching for specific queue features, or are there application-level patterns you prefer to ensure no messages are ever lost, even in the face of broker failures