Other than that, yes, durable execution does all of this for you.
TLDR on Durable Endpoints: you can automatically use steps in API endpoints which checkpoint state in the BG, and then retry on failure. This means you can run jobs in the background _somewhat_ transactionally (somewhat because there's delay between checkpointing) to minimize any tradeoffs here. And, if you want full transactionality, don't buffer checkpoints in the BG and instead do it synchronously.
Also, Redis is good for medium scale load. We're hitting millions of RPS (aggregated) on our services (I work at Inngest) and it doesn't scale so well at this load, at all. We had to invest in other infra.
With in-app queues you get the nice property that the job can be created in the same DB transaction, which is harder to keep once the runner lives outside the app.
I'm trying to understand if the simplicity of an external runner is worth that trade-off for smaller apps.
Where Redis genuinely makes more sense: fan-out pub/sub to many subscribers, rate-limiting across distributed nodes, or burst volumes where Postgres lock contention shows up. For most indie SaaS those thresholds are rarely hit.
The HTTP callback model you are exploring is roughly what Inngest and Trigger.dev offer. It works, but you give up transactional job creation -- inserting into your jobs table in the same transaction as your domain write. Without that, an app crash between row saved and job enqueued creates silent failures.