@LostKobrakai - thank you for your clear explanations.
It’s Mail Transport Agent. In the case I mentioned it’s local sendmail (alternative). It has its own persistent queue, work schedule, failure notification, etc.). If that’s not available or an external mail dispatch service is to be employed, I’ve also been using other persistent queue/deferred job implementations, Sidekiq as an example.
Just to make sure - the way I mentioned does have persistent queue and does notify once it gives up trying (email bounces to appropriate address and is distributed among those who are supposed to care), it also keeps logs, and all. The main difference as I see it now that in my example a) the responsibility is delegated to the MTA, which is a good thing - less code in the application, and b) it is not really transactional, which is a bad thing as the queue insertion may fail once the record is saved. Yes, I handle the errors but it’s not guaranteed to cover all situations. Which brings me back to where (and why) I started the thread. While putting non-DB operations in a DB transaction block is possible, it has its own problems. From the discussion here I understand that maintaining own queue and using a transactional queue insertion with Oban is the way to go with this kind of problem.