Ask HN: How do you decouple transactional messaging from your application code?
I worked for 2 large companies that compiled (in back-end language for ex. ASP.net/JSP template) and sent transactional email messages synchronously in response to some action. Unsurprisingly, they lost messages when they exceeded their SMTP relay rate limit or when their email provider blocked their account for compliance reasons. In addition, any template changes were coupled to their application release cycle.
Obviously, these were not architected to scale. One of the companies fixed it by implementing an in-house priority-based queue, a separate template repository, micro-services for rendering/sending, etc... took serious effort.
I am curious:
a) Is this common? Even some open-source modern projects seem to send transactional messages on the fly without a retry/queuing mechanism?
b) What are the general best practices when it comes to queuing transactional messages and managing their templates?
Obviously, these were not architected to scale. One of the companies fixed it by implementing an in-house priority-based queue, a separate template repository, micro-services for rendering/sending, etc... took serious effort.
I am curious:
a) Is this common? Even some open-source modern projects seem to send transactional messages on the fly without a retry/queuing mechanism?
b) What are the general best practices when it comes to queuing transactional messages and managing their templates?
Thanks!