Hacker News Reader

Comment by cyco130 | Hacker News Reader

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.

View on HN

There'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)

For 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

I 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.

I was going to write this as this is how I would do it but you beat me to it. +1

Reply on news.ycombinator.com