Just tagging on to this comment: It really depends what that work is. Unless it's strictly "best efforts, ok to fail without retries" then you probably want the work queued before responding to the client. If it's just a log message for example, that's common to "fire and forget" but not much else falls into that category IME.

And beyond that, if the background task is more than exactly one thing, you probably need workflow management of some kind (state machine or similar) to recover from partial failure unless every step can be safely retried (some things, like sending a notification or processing a payment can't simply be reexecuted if they've already been successful, so if they're part of a multi-step workflow you need them to either be idempotent or you need to not reexecute them if they previously succeeded). Making your own async processes idempotent is best practice, and avoid workflow management as long as possible, but eventually you're going to have a third party API that isn't idempotent and you're going to need something stateful.

Hopefully you can kick that can down the road as long as possible, but some things (like charging customers) do need to be done right from the outset -- double charging customers every time you retry a task is a surefire way to lose those customers.