Enqueue inside the database transaction or after commit, where do you put it?

The race you described is real and faster than people expect. I instrumented ours after chasing exactly this bug: our workers were picking jobs off Redis in single digit milliseconds, and the transaction that created the row took a good deal longer than that under load because of a trigger nobody remembered writing. So the job genuinely arrived before the data existed, hundreds of times a day, and every one of those became a not-found in the logs that we had learned to ignore. The gap is not theoretical, and it gets worse under exactly the load where you least want mysterious failures.

If your framework has an after-commit hook, use it, and understand what it does and does not promise. It removes the rollback problem completely, which is the failure that produces user visible nonsense like an email about a cancelled order. It does not remove the crash-in-the-gap problem, because nothing running in your process can. For a lot of applications that is an acceptable trade, and it is one line of code rather than a new component. Just be honest that you have chosen the silent-loss failure over the phantom-job failure rather than solved anything.

Going to disagree with the outbox recommendation for most teams, at least as a first move. Retrying on not-found with a short backoff solves the race, costs one line in the worker, and covers the overwhelming majority of real occurrences, because the gap is milliseconds and the retry lands after the commit. Combine that with an after-commit enqueue and you have handled both the rollback case and the visibility race for a fraction of the effort. Reach for an outbox when you can measure that you are losing jobs, not because a blog post says dual writes are unsound.

This is the dual write problem and there are only two honest solutions. Either the job lives in the same database as the data, so the enqueue is part of the same transaction and commits or rolls back with it, or you write an outbox row inside the transaction and a separate process moves outbox rows into Redis. Everything else is choosing which failure you would rather have.

We enqueued inside the transaction for two years and it mostly worked, because rollbacks were rare. Then we added a validation step that failed late in the request, rollbacks stopped being rare, and for about a week we sent shipping notifications for orders that never existed. Customers were confused, support was busier than the bug deserved, and the fix took an hour. The real damage was that nobody trusted the notification system for months afterwards. Correct beats convenient on anything a customer sees.

Same database as the data, or an outbox. After-commit if you accept the crash window. Never inside the transaction with an external queue.