Backend, APIs & data · Mixed

Outbound email, messages and webhooks

In one line: Outbound messages are a public interface: they need a queue, retries, and a record of what was sent to whom.

Email that reaches its destination

Set up sender-authentication records on the domain — without them, mail falls to spam, and that's not a bug in the code. Separate transactional from marketing mail, ideally on a separate subdomain, so marketing doesn't harm critical messages.

Monitor bounces and complaints. An address that fails repeatedly should be blocked automatically.

Outbound webhooks

If you notify customers' systems, you're committing: a signature that lets them verify the message is from you, a unique identifier per event, retries with delay, and a screen where the customer sees what was sent and what failed.

Declare explicitly that a message may be sent more than once — so the other side handles duplication.

Hygiene

Templates in one place, support for Hebrew and directionality, an unsubscribe link where required, and a record of every send with an identifier that lets you trace a customer's inquiry within a minute.

Going deeper

Don't send messages from within the user's request. Write to a queue, return a response, and send in the background. Beyond speed, this guarantees that when the mail provider is slow or down, the user doesn't get an error on an action that succeeded.