Webhook zeitversetzt senden: Architekturmuster, Zustellgarantien und die DSGVO-Frage

Einen Webhook zeitversetzt senden zu wollen, klingt nach einem Nebenschauplatz – bis man merkt, dass der Zeitversatz die Anforderungen an das System vollständig verändert. Ein synchroner Webhook ist ein Transportvorgang: Ereignis tritt ein, HTTP-Request geht raus, fertig. Ein verzögerter Webhook ist etwas anderes. Zwischen Registrierung und Auslieferung liegen Minuten, Tage oder Wochen, in denen der Auftrag samt Payload irgendwo liegen muss. Aus Transport wird Speicherung – technisch und datenschutzrechtlich.

Typische Anlässe, einen Webhook zu planen, kennt jedes Team:

• Trial-Ablauf: 14 Tage nach Registrierung soll die eigene Anwendung benachrichtigt werden, um Downgrade und Abschluss-E-Mail auszulösen.
• Reminder und Follow-ups: 24 Stunden vor einem Termin, drei Tage nach einer unbeantworteten Anfrage.
• Verzögerte Verarbeitung: Ein Import soll nicht sofort laufen, sondern nachts, wenn die API des Zielsystems nicht unter Last steht.
• Cool-down-Fenster: Eine Stornierung soll erst nach Ablauf einer Widerrufsfrist final verarbeitet werden.
• Retry auf Anwendungsebene: Ein fehlgeschlagener Drittsystem-Aufruf soll in 30 Minuten erneut angestoßen werden, aber ohne dass ein Prozess so lange offen bleibt.

In allen Fällen ist die Fragestellung dieselbe: Wer hält den Auftrag vor, wer garantiert die Auslieferung, und was liegt dabei in wessen Datenbank.

Technische Ansätze: Webhook planen im eigenen Stack

Der naive Weg

setTimeout, sleep, ein offener Worker-Thread. Funktioniert im Prototyp und bricht beim ersten Deployment. Der Zustand lebt ausschließlich im Prozessspeicher: Neustart, Crash, Scale-in oder ein rollendes Update löschen alle ausstehenden Aufträge, ohne Spur. Für Verzögerungen jenseits weniger Sekunden ist das kein Muster, sondern eine latente Datenverlustquelle.

Datenbanktabelle plus Poller

Der solide Klassiker: eine Tabelle mit due_at, payload, status, attempts, dazu ein Cron-getriebener Worker, der fällige Zeilen abräumt – in PostgreSQL üblicherweise mit SELECT ... WHERE due_at <= now() AND status = 'pending' FOR UPDATE SKIP LOCKED, um Mehrfachzustellung bei parallelen Workern zu vermeiden.

Das trägt weit. Der Aufwand steckt nicht im Happy Path, sondern in allem daneben: Idempotenz, Backoff-Strategie, Dead-Letter-Handling, Zeitzonen und Sommerzeitwechsel bei kalendarischen Terminen, Monitoring darüber, ob der Poller überhaupt noch läuft. Erfahrungsgemäß ist die zweite Hälfte davon in den meisten Projekten nicht gebaut, sondern nur geplant.

Queues mit Delay

Message-Broker bieten verzögerte Zustellung an, teils nativ, teils über Plugins oder Sorted-Set-Konstruktionen. Für kurze Verzögerungen funktioniert das gut. Für lange Horizonte wird es unhandlich: Einige Managed Queues begrenzen die maximale Verzögerung auf wenige Minuten, geplante Nachrichten lassen sich häufig nicht mehr auflisten, ändern oder stornieren, und Sichtbarkeit über den Bestand ausstehender Aufträge fehlt.

Dedizierter Scheduling-Dienst

Hier registriert die eigene Anwendung per API einen Auftrag mit Ziel-URL, Ausführungszeitpunkt und Payload; der Dienst stellt zu und protokolliert. Der Reiz liegt darin, dass Persistenz, Retries, Zeitzonenlogik und Zustellprotokolle ausgelagert sind. Der Preis: Ein weiterer Dienst hält die Payload – und damit gegebenenfalls personenbezogene Daten.

Zustellung, Retries und Signaturen bei verzögerten Webhooks

Wer einen Webhook zeitversetzt senden lässt, sollte drei Mechanismen unabhängig von der gewählten Architektur voraussetzen:

Retries mit exponentiellem Backoff und Jitter. Ein Zielsystem, das zum geplanten Zeitpunkt nicht erreichbar ist, darf den Auftrag nicht verlieren. Sinnvoll sind wachsende Abstände (etwa 30 s, 2 min, 10 min, 1 h, 6 h), zufälliger Versatz gegen Thundering Herds, eine harte Obergrenze an Versuchen und ein Dead-Letter-Zustand, der sichtbar ist statt still zu scheitern. 429 mit Retry-After sollte respektiert werden.

Idempotenz. Bei At-least-once-Zustellung – und praktisch jeder ernstzunehmende Dienst garantiert genau das, nicht Exactly-once – muss der Empfänger doppelte Zustellungen erkennen. Üblich ist ein stabiler Idempotency-Key im Header, den der Empfänger für ein definiertes Fenster vorhält.

Signierte Payloads. Eine öffentlich erreichbare Webhook-URL ist ein offener Endpunkt. Standard ist ein HMAC-SHA256 über Zeitstempel und Rohbody, übertragen in einem Header, plus Replay-Schutz durch ein enges Zeitfenster und die Möglichkeit, Secrets ohne Downtime zu rotieren. Wichtig für die Implementierung: Die Signatur muss über den unveränderten Rohbody gebildet werden, nicht über ein re-serialisiertes JSON.

Dazu kommen Delivery-Logs: HTTP-Status, Antwortzeit, Versuchsnummer, Fehlermeldung. Ohne sie ist ein verzögerter Webhook nicht debuggbar. Mit ihnen entsteht allerdings ein zweiter Datenbestand – dazu gleich mehr.

Der DSGVO-Haken: was liegt wo, wenn ein Webhook zeitversetzt gesendet wird

Der entscheidende Unterschied zum synchronen Fall: Der Payload wird gespeichert, oft über Wochen. Und Payloads von Reminder- oder Trial-Webhooks enthalten fast immer personenbezogene Daten im Sinne von Art. 4 Nr. 1 DSGVO – E-Mail-Adresse, Nutzer-ID, Name, Vorgangsnummer, manchmal ganze Vertragsdatensätze.

Daraus folgt in der Regel:

Auftragsverarbeitung nach Art. 28 DSGVO. Verarbeitet ein externer Scheduling-Dienst personenbezogene Daten weisungsgebunden für den Verantwortlichen, liegt Auftragsverarbeitung vor; ein Vertrag mit den Mindestinhalten des Art. 28 Abs. 3 DSGVO ist dann Pflicht. Der Umkehrschluss gilt ebenso: Enthält der Payload keinerlei Personenbezug, entfällt diese Pflicht – ein Argument für schlanke Payloads.

Technische und organisatorische Maßnahmen nach Art. 32 DSGVO. Relevant sind hier vor allem Verschlüsselung während der Übertragung und im Ruhezustand, Zugriffskontrolle auf die Auftragsdaten und ein belastbares Löschkonzept.

Datenminimierung und Speicherbegrenzung, Art. 5 Abs. 1 lit. c und lit. e DSGVO. Das architektonisch sauberste Muster für geplante Webhooks ist der schlanke Payload: Der Auftrag transportiert nur eine Referenz ({"event":"trial_expiry","ref":"a7f3..."}), und das empfangende System liest die eigentlichen Daten aus der eigenen Datenbank. Damit verlässt kein personenbezogenes Datum das eigene System, und die Frage nach dem AVV entschärft sich erheblich. Wo das nicht geht, sollten Aufbewahrungsfristen für Auftrag und Delivery-Log getrennt definiert und kurz gehalten werden.

Drittlandtransfer, Art. 44 ff. DSGVO. Sitzt der Dienst oder einer seiner Subprozessoren außerhalb der EU/des EWR, greift Kapitel V der DSGVO. Nach der Schrems-II-Entscheidung des EuGH (Urteil vom 16.07.2020, C-311/18) genügt der bloße Abschluss von Standardvertragsklauseln nicht; erforderlich ist zusätzlich eine Transfer-Impact-Analyse. Für die USA existiert seit Juli 2023 ein Angemessenheitsbeschluss (EU-US Data Privacy Framework), dessen Bestand jedoch Gegenstand laufender rechtlicher Auseinandersetzung ist und dessen aktueller Status vor jeder Entscheidung geprüft werden sollte.

Subprozessoren, Art. 28 Abs. 2 und 4 DSGVO. Bei vielen US-gehosteten Anbietern und auch bei europäischen Diensten, die auf US-Hyperscaler aufsetzen, liegt der eigentliche Aufwand nicht im Hauptvertrag, sondern in der Subprozessorenkette. Sie sollte vollständig dokumentiert und nachvollziehbar sein, bevor produktive Daten fließen.

Praktisch relevant ist außerdem, dass Auftragsverarbeiter ein eigenes Verzeichnis nach Art. 30 Abs. 2 DSGVO führen und Verletzungen des Schutzes personenbezogener Daten dem Verantwortlichen unverzüglich melden müssen (Art. 33 Abs. 2 DSGVO).

Checkliste: Anbieterauswahl für geplante Webhooks

• Hostingstandort eindeutig benannt, nicht nur „EU-Region" eines global operierenden Betreibers.
• Subprozessorenliste öffentlich oder auf Anfrage verfügbar, inklusive Hoster, E-Mail- und Monitoring-Dienstleistern.
• AVV mit den Mindestinhalten des Art. 28 Abs. 3 DSGVO, tatsächlich unterzeichenbar – nicht nur als Erwähnung in den AGB.
• TOM-Dokumentation nach Art. 32 DSGVO, konkret genug, um sie in die eigene Dokumentation zu übernehmen.
• Löschfristen für Auftragspayloads und Delivery-Logs, dokumentiert und konfigurierbar.
• Payload-Handling: Unterstützt der Dienst schlanke Referenz-Payloads, oder erzwingt das Format Datenmitgabe?
• Signaturverfahren und Secret-Rotation vorhanden.
• Retry-Verhalten dokumentiert: Anzahl, Abstände, Dead-Letter-Zustand, Idempotency-Header.
• Transparenz über den Auftragsbestand: Sind geplante Webhooks auflistbar, änderbar, stornierbar?
• Exit: Lassen sich ausstehende Aufträge exportieren, wenn man den Dienst verlässt?

Klassische Dienste ohne AVV fallen bei Punkt drei aus, unabhängig davon, wie gut die technische Umsetzung ist.

Wie cronplan den Fall angeht

• Betrieb ausschließlich auf Servern von Hetzner in Deutschland (Falkenstein und Nürnberg).
• Keine US-Subprozessoren. E-Mail-Versand über Brevo (französischer Anbieter, EU-Hosting), Reichweitenmessung über selbst gehostetes, cookieloses Umami.
• Ein AVV auf Basis der Standardvertragsklauseln der EU-Kommission für Auftragsverarbeitung nach Art. 28 Abs. 7 DSGVO (Durchführungsbeschluss (EU) 2021/915), ergänzt um eigene Anlagen (Verarbeitungsbeschreibung, TOMs, Subprozessorenliste). Dieses Dokument befindet sich aktuell in juristischer Prüfung und ist noch nicht unterzeichenbar; Early-Access-Interessenten erhalten es, sobald die Prüfung abgeschlossen ist.