SMTP-E-Mails in Node.js zuverlässig im Hintergrund versenden

Eine Kampagnenfreigabe, eine Kontostandsänderung oder ein Sicherheitsalarm sollte nicht dazu führen, dass eine Node.js-Anfrage auf einen Mailserver warten muss. Ist das Relay langsam, kann die Aktion für den Nutzer in einen Timeout laufen. Wiederholt die App die Anfrage, wird dieselbe Nachricht möglicherweise doppelt versendet. Eine sicherere Lösung für den Produktivbetrieb: Die Benachrichtigung wird zusammen mit dem Geschäftsereignis gespeichert und anschließend von einem Hintergrund-Worker per SMTP versendet.

E-Mails in Node.js im Hintergrund versenden

Stellen Sie sich bei einem Krypto-Werbenetzwerk eine Kampagne vor, deren Status von „Ausstehend“ auf „Genehmigt“ wechselt. Die Anwendung sollte diese Statusänderung umgehend speichern. Sie sollte nicht davon abhängig sein, dass eine SMTP-Verbindung zustande kommt, bevor sie dem Werbetreibenden antworten kann.

Speichern Sie einen E-Mail-Auftrag in einer Datenbanktabelle oder einer dauerhaften Warteschlange – und zwar innerhalb derselben Transaktion wie die Statusänderung. Ein Worker liest ausstehende Aufträge aus und versendet sie über das Relay. So sind die Verfügbarkeit der Anwendung und der E-Mail-Versand – auch für „транзакційні та маркетингові повідомлення“ – voneinander entkoppelt: Bei einem vorübergehenden Ausfall des Relays verzögert sich die Benachrichtigung, ohne dass eine Freigabe rückgängig gemacht oder eine Aktion im Dashboard blockiert wird.

Wenn Sie ein SMTP-Relay für Node.js in einen bestehenden Dienst integrieren, sollte die Abgrenzung zum Worker Ihre wichtigste Designentscheidung sein – nicht die Wahl der Mail-Bibliothek. Die E-Mail- und Messaging-Plattform kann die SMTP-Verbindung für Transaktionsnachrichten bereitstellen. Ihre Anwendung muss jedoch weiterhin festlegen, wann eine Nachricht erstellt wird, wie Wiederholungsversuche ablaufen und was bei ungewissem Zustellstatus geschieht.

Jedem Geschäftsereignis genau einen Benachrichtigungsauftrag zuordnen

Erstellen Sie den Auftrag, sobald das zugrunde liegende Ereignis gespeichert wird – nicht jedes Mal, wenn eine Seite geladen oder eine API-Anfrage wiederholt wird. Versehen Sie den Auftrag mit einem stabilen Ereignisschlüssel, zum Beispiel aus der Kampagnen-ID, dem Statusübergang und der Versionsnummer. Erzwingen Sie die Eindeutigkeit dieses Schlüssels, damit doppelte Anfragen nicht mehrere ausstehende Freigabe-E-Mails erzeugen.

Ein sinnvoller Auftragseintrag enthält den Empfänger, eine Vorlagen-ID, die zum Erstellen der Nachricht erforderlichen Mindestdaten, die Anzahl der Zustellversuche, den Zeitpunkt des nächsten Versuchs und den Status. Speichern Sie darin weder SMTP-Zugangsdaten noch unnötige Kontoinformationen. Falls sich die Empfängeradresse vor dem Versand ändern kann, legen Sie fest, ob der Auftrag die zum Zeitpunkt des Ereignisses erfasste Adresse oder die aktuell verifizierte Adresse des Kontos verwenden soll. Halten Sie diese Regel ausdrücklich fest.

Die versendete E-Mail sollte sich auf eine tatsächliche Statusänderung beziehen. Ein Worker sollte eine Freigabe nicht aus veralteten Warteschlangendaten ableiten. Vor dem Versand eines wichtigen Alarms kann er die aktuelle Ereignisversion prüfen oder den relevanten Datensatz laden. So vermeiden Sie, einem Kunden mitzuteilen, eine Kampagne sei genehmigt worden, obwohl sie kurz darauf pausiert wurde.

SMTP-Worker mit Nodemailer einrichten

Verwenden Sie einen gepflegten SMTP-Client wie Nodemailer und beziehen Sie die Verbindungsdaten aus der Umgebung des Workers, statt sie im Quellcode zu hinterlegen. Das folgende Beispiel verwendet den gängigen Submission-Port. Passen Sie Port und TLS-Einstellungen an die für Ihr Konto bereitgestellten Zugangsdaten an.

const nodemailer = require("nodemailer");

const port = Number(process.env.SMTP_PORT || 587);

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port,
  secure: port === 465,
  requireTLS: port !== 465,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

async function sendCampaignNotice(message) {
  return transporter.sendMail({
    from: process.env.MAIL_FROM,
    to: message.to,
    subject: message.subject,
    text: message.text,
    html: message.html
  });
}

Verwenden Sie als Absenderadresse eine Adresse, die für Ihre Versandkonfiguration freigegeben ist, und richten Sie für den Worker eigene Zugangsdaten ein, statt einen Administrator-Login wiederzuverwenden. Geben Sie weder die vollständige Nachricht noch Passwörter oder Authentifizierungsantworten in Protokollen aus. Eine Überprüfung beim Start kann ungültige Einstellungen erkennen, beweist aber nicht, dass ein bestimmter Empfänger eine spätere Nachricht annehmen wird.

E-Mail-Warteschlange mit Wiederholungsversuchen in Node.js

Klassifizieren Sie Fehler, statt jeden Fehler in gleichem Rhythmus erneut zu versuchen. Ein vorübergehender Verbindungsfehler oder eine Serverantwort, die auf eine Überlastung hinweist, kann mit zunehmend längeren Wartezeiten erneut geprüft werden. Ungültige Zugangsdaten, fehlerhafte Empfängeradressen und andere dauerhaft bestehende Konfigurations- oder Adressfehler müssen untersucht werden – schnelle Wiederholungen helfen hier nicht. Legen Sie eine maximale Anzahl von Versuchen fest und verschieben Sie ausgeschöpfte Aufträge in einen Status, den ein Operator prüfen kann.

Verwenden Sie eine Worker-Lease oder einen vergleichbaren Sperrmechanismus, damit nicht zwei Node.js-Prozesse gleichzeitig denselben ausstehenden Auftrag versenden. Wenn ein Worker einen Auftrag übernimmt, speichern Sie ein Ablaufdatum für die Lease. Wird der Prozess beendet, kann ein anderer Worker den Auftrag nach Ablauf der Lease erneut übernehmen. Legen Sie die Lease länger als das übliche Versand-Timeout fest und verlängern Sie sie, falls das Erstellen oder Zustellen der Nachricht länger dauern kann.

SMTP kann für Ihre Anwendung keine echte „Exactly-once“-Garantie bieten. Das Relay kann eine Nachricht annehmen, während die Verbindung abbricht, bevor Ihr Worker eine Bestätigung erhält. Ein erneuter Versuch kann in diesem Fall zu einer doppelten Nachricht führen; wird der Auftrag schon vor der Annahme als versendet markiert, kann die Nachricht hingegen verloren gehen. Verwenden Sie stabile Ereignisschlüssel, um doppelte Aufträge zu verhindern, begrenzen Sie Wiederholungsversuche und akzeptieren Sie, dass sich dieser seltene ungewisse Fall nicht immer automatisch auflösen lässt.

Die Änderung schrittweise und kontrolliert einführen

Bevor Sie den Produktivverkehr umstellen, versenden Sie Testaufträge aus einer Nicht-Produktivumgebung. Prüfen Sie, ob sich der Worker authentifizieren, die erwarteten Inhalte erstellen und Erfolgs- sowie Fehlerstatus speichern kann. Aktivieren Sie den Worker anschließend zunächst für einen Benachrichtigungstyp mit geringem Risiko. Vergleichen Sie die Anzahl der Geschäftsereignisse, der eingereihten Aufträge und der abgeschlossenen Sendungen. Ein wachsender Rückstand kann auf ein Worker- oder Konfigurationsproblem hinweisen, bevor Sie wichtige Alarme umstellen.

• Verwenden Sie während der Einführung dasselbe Nachrichtenschema in der Webanwendung und im Worker.
• Sorgen Sie für idempotente Auftragserstellung, bevor Sie mehrere Worker-Instanzen starten.
• Überwachen Sie das Alter der Warteschlangeneinträge, die Anzahl der Wiederholungen, dauerhafte Fehler und den Zustand der Worker.
• Halten Sie einen manuellen Weg zur erneuten Verarbeitung geprüfter Fehler bereit, statt blind alle fehlgeschlagenen Aufträge erneut zu versenden.

Sobald der Worker stabil läuft, entfernen Sie direkte SMTP-Versandaufrufe aus den Request-Handlern, damit es für diese Nachrichten nur noch einen kontrollierten Versandweg gibt. Wenn Sie die E-Mail- und Messaging-Plattform als Relay verwenden, übernimmt sie die SMTP-Übergabe. Für Warteschlange, Ereignisregeln, Wiederholungsrichtlinien und die betriebliche Prüfung bleiben Sie selbst verantwortlich. Diese Aufteilung ist sinnvoll, wenn Kontoereignisse auch bei kurzen E-Mail-Ausfällen schnell erfasst werden müssen. Eine Überwachung oder klare Regeln für verzögerte Benachrichtigungen ersetzt sie jedoch nicht.