Benachrichtigungsdienstfeedback

Vorhanden

Dieser Funktionsbaustein ist dokumentiert und Teil des aktuellen D-Stack-Portfolios.

Erstellt am: 12. März 2026 | Autor: BMDS-Architekturteam

help Warum ist dieser Baustein für eine Enterprise-Architektur unverzichtbar?feedback

Digitale Verwaltungsprozesse erzeugen Ereignisse, über die Menschen und Systeme informiert werden müssen: Ein Antrag wurde eingereicht, ein Bescheid ist fertig, eine Frist läuft ab. Ohne einen zentralen Benachrichtigungsdienst müsste jede Fachanwendung eigene Versandlogik für E-Mail, SMS, Push und Brief implementieren. Das führt zu Inkonsistenzen, doppelten Kosten und erschwerter Wartung.

• Bürgernähe: Bürger:innen erwarten zeitnahe, kanalübergreifende Information über den Status ihrer Anliegen; das ist ein Kernziel des OZG.
• Compliance: Zustellnachweise, Fristwahrung und Protokollierung sind rechtlich vorgeschrieben (VwVfG, eIDAS).
• Effizienz: Ein zentraler Dienst vermeidet redundante Implementierungen in jeder Fachanwendung und senkt Betriebskosten.
• Skalierbarkeit: Massenversand (z. B. Steuerbescheide, Wahlbenachrichtigungen) erfordert eine asynchrone, hochverfügbare Infrastruktur.

settings Kernfunktionalitätenfeedback

Multi-Kanal-Versandfeedback

Kanal	Beschreibung	Einsatzszenario
E-Mail	SMTP-basierter Versand mit DKIM/SPF-Signatur	Standardkommunikation, Statusupdates
SMS	Gateway-Anbindung für Kurznachrichten	MFA-Codes, dringende Fristhinweise
Push-Notification	Web-Push und Mobile-Push (FCM/APNs)	Echtzeitbenachrichtigungen in Apps
De-Mail / beBPo	Rechtsverbindliche elektronische Zustellung	Bescheide, Verwaltungsakte
Briefpost (Fallback)	Integration mit Druckdienstleistern	Bürger:innen ohne digitalen Zugang

Template-Managementfeedback

• Mehrsprachige Vorlagen mit Platzhaltern für personalisierte Inhalte.
• Barrierefreiheit: Templates erfüllen BITV 2.0 / WCAG 2.1 AA für E-Mail und Web-Push.
• Versionierung: Änderungen an Templates werden versioniert und auditiert.
• A/B-Testing: Optionale Variantentests für Kommunikationsoptimierung.

Zustellnachweise und Protokollierungfeedback

• Zustellstatus-Tracking pro Empfänger:in und Kanal (zugestellt, gelesen, fehlgeschlagen).
• Revisionssichere Protokollierung aller Versandvorgänge für Nachweispflichten.
• Retry-Mechanismen bei temporären Zustellfehlern mit exponentieller Backoff-Strategie.
• Dead-Letter-Queue für dauerhaft unzustellbare Nachrichten mit Eskalationsworkflow.

Event-gesteuerte Architekturfeedback

• Asynchrone Verarbeitung über Message Queue (Kafka / RabbitMQ).
• Kanalrouting-Regeln: Empfängerpräferenzen bestimmen den Versandkanal.
• Rate Limiting: Schutz vor Massenversand-Missbrauch.
• Priority Queuing: Dringende Benachrichtigungen werden bevorzugt verarbeitet.

recommend Technologieempfehlungenfeedback

Komponente	Empfehlung	Begründung
Notification Engine	Novu / Notifir	Open Source, Multi-Channel, Template-basiert
Message Broker	Apache Kafka	Hochverfügbar, skalierbar, Event-Sourcing-fähig
Template Engine	MJML + Handlebars	Responsive E-Mail-Templates, erweiterbar
SMS Gateway	Open-Source-Gateway + Provider-API	Flexibler Provider-Wechsel ohne Vendor-Lock-in

link Bezug zu anderen Bausteinenfeedback

• Workflows: Workflow-Schritte lösen Benachrichtigungen aus (z. B. „Antrag genehmigt").
• Identität & Zugang: Empfänger:innen werden über IAM-Profile aufgelöst; Kontaktdaten stammen aus dem Verzeichnisdienst.
• Consent Management: Versand nur an Empfänger:innen mit gültiger Einwilligung für den jeweiligen Kanal.
• Ein- und Auszahlung: Zahlungsbestätigungen und Mahnungen werden über den Benachrichtigungsdienst versendet.
• Dokumentenmanagement: Bescheide als Dokumentenanhang an Benachrichtigungen.

gavel Relevante Standards und Vorgabenfeedback

• De-Mail-Gesetz (De-Mail-G)
• BSI TR-03116 (Kryptographische Vorgaben für eGovernment)
• VwVfG § 41 (Bekanntgabe von Verwaltungsakten)
• DSGVO Art. 7, 21 (Einwilligung und Widerspruch)
• Datenschutzvorgaben des Portals