4 ms·
If sending the email is mission critical you could start a transaction, update the DB, send the email, commit the transaction. Maybe slightly better is: start t
by cyco130 5y ago
If sending the email is mission critical you could start a transaction, update the DB, send the email, commit the transaction. Maybe slightly better is: start the transaction, update the DB, put the "send email" job in a job queue, commit the transaction. And the job queue takes care of sending the email, retrying on fail, notifying the admin if sending the email keeps failing etc.
- gabereiser 5y agoI was going to write this as this is how I would do it but you beat me to it. +1
- mustardo 5y agoFor your "maybe slightly better is" what happens when the db commit fails? FK constraint or some such, now you have sent an email (called the API) and have no record in your DB Without two phase commits I would 1) Write to the DB in the original POST request a record indicating that an email should be sent 2) Process that record outside of the original request and mark it as sent
- cyco130 5y agoI assumed the job queue was on the same database so either both would succeed or both would fail. Your should_send_email flag effectively corresponds to my job queue.
- vsroy 5y agoThere's one hole here where it feels like things could slip through. - You call the send email API but your server crashes before the API returns 200. This would be fine in the case of email servers (you just end up sending the email twice). It seems a lot less fine in the case of Stripe transactions. I guess, the concept of idem-potency keys can solve this issue. (https://brandur.org/idempotency-keys https://brandur.org/idempotency-keys)