Durchgang durch einen Benachrichtigungsdienst: Kanäle, Präferenzen, Zustellversuche und Wiederholungen

Ziel

Nachrichten von vielen Produzenten gemäss den Präferenzen der Nutzer über mehrere Kanäle zustellen, sodass kein Produzent direkt mit einem Provider spricht und eine Wiederholung nie doppelt versendet.

Voraussetzungen

Eine Liste der Kanäle (E-Mail, Push, SMS, In-App) und ihrer Provider, ein Katalog der Benachrichtigungstypen mit Standardkanal und Dringlichkeit je Typ sowie eine Richtlinie dazu, was ein Nutzer abschalten darf.

Schritte

1. Randbedingungen: Produzenten dürfen bei der Zustellung nicht blockieren; Provider fallen unabhängig voneinander aus; bei den meisten Typen ist ein Duplikat schlimmer als eine Verzögerung; Massenkampagnen dürfen transaktionale Nachrichten nicht verzögern.
2. Komponenten: eine Ingest-API, die (idempotency_key, recipient, type, payload) entgegennimmt und vor der Antwort eine Zeile schreibt; ein Router, der nach Prüfung von Präferenzen und Ruhezeiten eine Benachrichtigung in Zustellungen je Kanal auffächert; eine Warteschlange pro Kanal; Kanal-Worker, die Templates rendern und Provider aufrufen; ein Callback-Empfänger für Bounces, Beschwerden und ungültige Tokens.
3. Datenmodell: notification(id, idempotency_key unique, recipient, type, payload, created_at); delivery(id, notification_id, channel, address, status, attempts, next_attempt_at, provider_message_id, last_error); preference(recipient, type, channel, enabled); device_token(recipient, token, platform, invalidated_at). Der eindeutige Schlüssel macht Wiederholungen durch den Produzenten unschädlich.
4. Wiederholungen: Jeder Kanal hat seinen eigenen Backoff-Plan mit Jitter und einem Maximum; Provider-Fehler werden als wiederholbar (Timeouts, 5xx, Rate Limits) oder endgültig (ungültige Adresse, abgemeldet) eingestuft. Für Web Push verlangt RFC 8030 bei jeder Zustellanfrage einen TTL-Header in Sekunden und legt fest, dass der Push-Dienst nach dessen Ablauf keine Zustellung mehr versuchen darf; eine dringende Benachrichtigung sollte eine kurze TTL tragen, statt noch Stunden lang wiederholt zu werden, nachdem sie ihren Nutzen bereits verloren hat.
5. Fehlerbilder: Ein Worker stürzt ab, nachdem der Provider akzeptiert hat, aber bevor die Zeile aktualisiert wurde (ein Duplikat; die Provider-Nachrichten-ID aufbewahren, Provider mit idempotenten Send-APIs bevorzugen); ein Providerausfall lässt den Rückstau wachsen (zeitkritische Typen nach Alter verwerfen, statt sie verspätet zuzustellen); ein Template schlägt für eine Locale fehl (nur diese Zustellung scheitern lassen, nicht den Worker); Kampagnen verdrängen transaktionalen Verkehr (getrennte Warteschlangen oder Prioritäten); Tokens werden still ungültig (Callbacks verarbeiten und bereinigen).
6. Messen: Zeit vom Ingest bis zur Annahme durch den Provider je Kanal, Versuche je Zustellung, Rate endgültiger Fehlschläge nach Fehlerklasse, Alter der Warteschlange, Abmelderate je Typ.
7. Nicht zuerst: Multi-Provider-Failover, Sammelbenachrichtigungen und Batching, Ratenobergrenzen pro Nutzer, ein Template-Editor, Engagement-Analytics, Text-Experimente.

Erwartetes Ergebnis

Produzenten rufen eine einzige API auf; jede Zustellung wird entweder von einem Provider bestätigt, scheitert endgültig mit einem Grund, oder ist noch eingeplant; das erneute Absenden einer Produzentenanfrage erzeugt keine zweite Nachricht.

Grenzen und Prüfbasis

Vorgeschlagener Entwurf, keine Messungen. Die Duplikatunterdrückung an der Providergrenze hängt vom Provider ab; ohne idempotente Send-API nimmt der Entwurf seltene Duplikate nach einem Absturz in Kauf.