Transaktionale E-Mails zuverlässig versenden: Outbox-Zeile, Worker, Retries und Idempotenzschlüssel

Ziel

Jede Bestellbestätigung, jeder Passwort-Reset oder jede Rechnung verlässt das System genau einmal, übersteht Prozessabstürze und Ausfälle des Anbieters, und lässt sich vom Geschäftsereignis bis zur Nachrichtenkennung des Anbieters zurückverfolgen.

Voraussetzungen

Ein dauerhafter Speicher (die eigene Datenbank der Anwendung genügt), ein Worker-Prozess, ein über SMTP oder HTTP erreichbarer Anbieter oder MTA, sowie eine Message-ID-Konvention. Der zitierte RFC 5321 teilt negative Antworten in vorübergehende (4yz: dieselbe Anfrage kann später erfolgreich sein) und dauerhafte (5yz: die Anfrage nicht unverändert wiederholen) Klassen; der zitierte RFC 5322 verlangt, dass die Message-ID ein global eindeutiger Bezeichner ist.

Schritte

1. In derselben Datenbanktransaktion, die das Geschäftsereignis erfasst, eine outgoing_email-Zeile einfügen: Empfänger, Vorlagenname, gerenderte Parameter, ein aus dem Ereignis abgeleiteter Idempotenzschlüssel (order-1234-confirmation), eine frisch erzeugte Message-ID und der Status pending. Das ist das Outbox-Muster, angewendet auf E-Mail.
2. Ein Worker beansprucht einen Batch ausstehender Zeilen (in PostgreSQL: SELECT ... FOR UPDATE SKIP LOCKED), rendert die Nachricht und ruft den Anbieter mit der gespeicherten Message-ID und, sofern die API einen akzeptiert, dem Idempotenzschlüssel auf.
3. Das Ergebnis klassifizieren. 4yz-Antworten, Verbindungsfehler und Timeouts sind wiederholbar: die Zeile behalten, attempts erhöhen, next_attempt_at mit exponentiellem Backoff und Jitter setzen. 5yz-Antworten und abgelehnte Adressen sind endgültig: mit dem Antworttext als failed markieren und abbrechen.
4. Versuche und Alter begrenzen. RFC 5321 besagt, dass die Aufgabezeit eines MTA im Allgemeinen mindestens 4–5 Tage betragen muss; eine Anwendungswarteschlange begrenzt üblicherweise deutlich früher, und Zeilen jenseits der Grenze wechseln in einen Dead-Letter-Status, der einen Alarm auslöst.
5. Die Nachrichtenkennung des Anbieters und Zeitstempel an der Zeile speichern, damit sich Bounces, Beschwerden und Support-Anfragen dem Ereignis wieder zuordnen lassen.
6. Den Worker so gestalten, dass er parallel und nach Abstürzen sicher läuft: Der eindeutige Idempotenzschlüssel oder die Message-ID verhindert einen zweiten Versand, wenn der Prozess zwischen „Anbieter hat akzeptiert“ und „Zeile als gesendet markiert“ abstürzt.
7. Für zeitkritische E-Mails (Login-Codes, Resets) und alles andere separate Warteschlangen oder Prioritäten verwenden, damit ein Massenversand keinen Code verzögern kann.

Erwartetes Ergebnis

Versendungen überstehen Neustarts; ein Ausfall des Anbieters zeigt sich als wachsende Zahl ausstehender Zeilen statt als verlorene E-Mail; Duplikate nach einem Absturz werden durch den Schlüssel verhindert, nicht durch Zufall.

Grenzen und Prüfbasis

„Exactly once“ gilt nur bis zur API des Anbieters: Ein Anbieter, der die Anfrage angenommen, aber nie geantwortet hat, kann trotzdem gesendet haben, und anbieterseitige Idempotenzschlüssel werden meist nur für einen vom Anbieter dokumentierten Zeitraum berücksichtigt. Testen, indem der Worker zwischen Senden und Als-gesendet-markieren beendet wird, und indem 4yz- und 5yz-Antworten simuliert werden. Basierend auf den zitierten RFCs und dokumentierter Praxis; es werden keine Zeit- oder Ratenangaben behauptet.