Webhooks vs Polling: die richtige Integrationsstrategie wählen

Welches Problem lösen wir, wenn wir Daten synchronisieren?

Synchronisieren klingt nach „Updates schnell anzeigen“, aber die eigentliche Aufgabe ist härter: zwei Systeme dazu bringen, sich auf den gleichen Sachverhalt zu einigen — auch wenn Nachrichten zu spät, doppelt oder gar nicht ankommen.

Bei Webhooks vs Polling unterscheidet sich die Art, wie du erfährst, dass sich etwas geändert hat.

Ein Webhook ist Push. System A ruft deinen Endpoint auf, wenn ein Event passiert (zum Beispiel „invoice paid“). Polling ist Pull. Dein System fragt System A in einem Zeitplan: „Gibt es etwas Neues seit dem letzten Mal?“

Systeme synchron zu halten bedeutet gewöhnlich, sowohl Events als auch State zu verfolgen. Events sagen, was passiert ist. State sagt, wie der Datensatz gerade aussieht. Die Reihenfolge ist wichtig, weil Integrationen selten in perfekter Reihenfolge laufen. Ein "updated"-Event kann vor "created" ankommen, doppelt eintreffen oder gar nicht.

Das Ziel ist korrekte Daten, nicht nur frische Daten. „Korrekt“ heißt: Du verpasst keine Änderungen, wendest dieselbe Änderung nicht zweimal an, kannst nach Ausfallzeiten ohne manuelle Aufräumarbeiten wiederherstellen und nachweisen, was du wann verarbeitet hast.

Ein praktisches Beispiel: Dein Zahlungsanbieter sendet einen Webhook wie „payment_succeeded“. Deine App legt eine Bestellung an und markiert sie als bezahlt. Wenn dein Webhook-Endpoint kurz ausfällt, siehst du dieses Event vielleicht nie. Ein Polling-Job, der nach Zahlungen fragt, die „seit gestern“ aktualisiert wurden, kann die Lücke schließen und den Bestellstatus korrigieren.

Die meisten realen Integrationen verwenden am Ende beides: Webhooks für Geschwindigkeit, Polling zum Nachfüllen und Verifizieren. Die Methode ist weniger wichtig als die Sicherheitsvorkehrungen darum herum.

Latenz und Aktualität: wie schnell Updates wirklich ankommen

Wenn Leute Webhooks vs Polling vergleichen, meinen sie oft eine Sache: wie schnell bemerkt deine App eine Änderung anderswo. Diese Aktualität ist nicht nur nett — sie beeinflusst Support-Tickets, doppelte Arbeit und ob Nutzer dem angezeigten Zustand vertrauen.

Polling hat eine eingebaute Verzögerung, weil du nur nach einem Zeitplan fragst. Wenn du alle 5 Minuten pollst, kann ein Update zwischen wenigen Sekunden und fast 5 Minuten verspätet eintreffen, zuzüglich API-Antwortzeit. Häufigeres Polling verbessert die Aktualität, erhöht aber API-Aufrufe, Kosten und die Wahrscheinlichkeit, Limits zu erreichen.

Webhooks können sich nahezu in Echtzeit anfühlen, weil der Anbieter ein Event sofort nach dem Geschehen schickt. Aber sie sind nicht instant oder garantiert. Anbieter können Events bündeln, später erneut versuchen oder die Lieferung pausieren. Dein System fügt ebenfalls Verzögerung hinzu (Queue-Staus, Datenbank-Locks, Deploys). Eine realistischere Erwartung ist: schnell, wenn alles gesund ist; eventual consistency, wenn nicht.

Die Form des Traffics spielt eine Rolle. Polling erzeugt gleichmäßige, vorhersehbare Last. Webhooks sind bursty: eine geschäftige Stunde kann Hunderte Events in einer Minute senden, dann wieder nichts. Wenn du Webhooks akzeptierst, rechne mit Spitzen und plane, Events in eine Queue zu legen, damit du sie kontrolliert verarbeiten kannst.

Bevor du irgendetwas entwirfst, wähle ein Ziel-Fenster für Aktualität:

• Sekunden: nutzerorientierte Benachrichtigungen, Chat, Zahlungsstatus
• Minuten: Support-Tools, Admin-Ansichten, leichte Reports
• Stunden: nächtliche Abgleiche, Low-Priority-Analytics

Wenn das Vertriebsteam neue Leads innerhalb einer Minute sehen muss, bringen Webhooks dich dorthin. Ein „Safety Poll“ alle paar Stunden kann verpasste Events noch aufspüren und den endgültigen Zustand bestätigen.

Ausfallmodi, die du in Produktion wirklich sehen wirst

Die meisten Integrationen fallen auf langweilige, wiederkehrende Arten aus. Die Überraschung ist nicht, dass etwas kaputtgeht — sie ist, dass es still kaputtgeht. Geschwindigkeit ist leicht diskutiert. Zuverlässigkeit ist, wo die eigentliche Arbeit liegt.

Polling-Fehler sehen oft so aus, als hätten wir „die Aktualisierung nicht gesehen“, selbst wenn der Code in Ordnung scheint. Timeouts können eine Anfrage halb abschneiden. Teilantworten können durchrutschen, wenn du nur auf HTTP 200 prüfst und den Body nicht validierst. Pagination-Änderungen sind ebenfalls häufig: eine API ändert die Sortierreihenfolge, Page-Regeln oder wechselt von Seitenzahlen zu Cursors, und du überspringst oder wiederholst Einträge. Ein weiterer klassischer Fehler ist, "updated_since" mit deiner lokalen Uhr zu filtern und dann Updates zu verpassen, wenn Uhren driften oder der Anbieter ein anderes Zeitstempelfeld nutzt.

Webhooks fallen anders aus. Die Zustellung ist meist "at least once", also retryt der Anbieter bei Netzwerkfehlern und du wirst Duplikate sehen. Wenn dein Endpoint 10 Minuten down ist, bekommst du später möglicherweise einen Schwall alter Events. Signaturvalidierungsprobleme sind ebenfalls häufig: ein Secret rotiert, du validierst die falsche Rohlast oder ein Proxy ändert Header, und plötzlich sehen gültige Events ungültig aus.

Der gemeinsame Ausfallmodus bei beiden Ansätzen sind Duplikate und außer-Reihenfolge-Auslieferung. Geh davon aus, dass du dasselbe Event mehrmals erhältst, Events spät ankommen, in falscher Reihenfolge eintreffen und Payloads Felder vermissen, die du erwartet hast.

„Exactly once“ bekommst du so gut wie nie. Designe für „at least once“ und mache die Verarbeitung sicher. Speichere einen Idempotency-Key (Event-ID oder Provider-Objekt-Version), ignoriere Wiederholungen und wende Updates nur an, wenn sie neuer sind als das, was du gespeichert hast. Logge außerdem, was du erhalten und was du damit gemacht hast, damit du Replay zuverlässig durchführen kannst statt zu raten.

Rate-Limits und Kosten: API-Nutzung unter Kontrolle halten

Rate-Limits sind der Punkt, an dem Webhooks vs Polling aus der Theorie ein Budget- und Zuverlässigkeitsproblem wird. Jeder zusätzliche Request kostet Zeit und Geld und kann deine Beziehung zum Anbieter belasten.

Polling frisst Kontingente, weil du auch dann zahlst, wenn sich nichts geändert hat. Es wird schlimmer, wenn Limits pro Nutzer oder Token gelten: 1.000 Kunden, die jede Minute pollen, sehen für den Anbieter aus wie ein Angriff, selbst wenn jeder Kunde „wohlverhalten“ ist. Polling multipliziert Aufrufe außerdem leicht (Listen-Endpunkte, dann Details für jedes Item abfragen), so triffst du die Grenze unerwartet.

Webhooks reduzieren in der Regel API-Calls, erzeugen aber Spitzenbelastung. Ein Anbieter kann nach einem Ausfall, Bulk-Import oder Produkt-Launch tausende Events auf einmal liefern. Einige werden dich mit 429 drosseln, einige retryen aggressiv, andere verwerfen Events, wenn dein Endpoint langsam ist. Auf deiner Seite brauchst du Backpressure: akzeptiere schnell, queue die Arbeit und verarbeite sie in einem sicheren Tempo.

Um Calls zu reduzieren ohne Korrektheit zu verlieren, konzentriere dich auf einige Muster, die sich in der Praxis bewährt haben:

• Inkrementelles Synchronisieren per "updated since"-Zeitstempeln oder Change-Tokens
• Serverseitiges Filtern (nur die Event-Typen abonnieren, die du brauchst)
• Batching von Reads und Writes (Details in Chargen holen, Bulk-Schreibvorgänge)
• Caching stabiler Referenzdaten (Tarife, Statuslisten, Benutzerprofile)
• Trennung von "Realtime" und "Reporting" (Fast-Path vs nächtliche Jobs)

Plane Peaks vor ihrem Eintreten. Halte einen dedizierten Backfill-Modus bereit, der langsamer läuft, Kontingente respektiert und pausier-/fortsetzbar ist.

Die richtige Herangehensweise wählen: eine einfache Entscheidungsanleitung

Die Wahl Webhooks vs Polling läuft meist auf Folgendes hinaus: brauchst du Geschwindigkeit, oder brauchst du einen einfachen, vorhersehbaren Weg, Updates zu bekommen, selbst wenn der Vendor unzuverlässig ist?

Polling ist oft die bessere Default-Wahl, wenn der Drittanbieter keine Webhooks anbietet oder wenn dein Workflow eine Verzögerung toleriert. Es ist außerdem leicht zu verstehen, wenn du nur eine tägliche oder stündliche Synchronisation brauchst und die API einen klaren "updated since"-Filter hat.

Webhooks sind die bessere Default-Wahl, wenn Zeit eine Rolle spielt: „neue Bestellung eingegangen“, „Zahlung fehlgeschlagen“, „Ticket zugewiesen“. Sie reduzieren unnötige API-Calls und können Arbeit sofort auslösen.

Eine praktische Regel ist, beides zu nutzen, wenn Korrektheit wichtig ist. Lass Webhooks die Geschwindigkeit liefern und Polling das Aufräumen übernehmen. Zum Beispiel: verarbeite Webhooks schnell und führe dann alle 15 Minuten (oder alle paar Stunden) einen Poll durch, um Lücken durch verwaiste Events oder temporäre Ausfälle zu schließen.

Eine kurze Anleitung:

• Wenn Minuten Verzögerung okay sind, starte mit Polling.
• Wenn Updates innerhalb von Sekunden sichtbar sein müssen, starte mit Webhooks.
• Wenn der Vendor unzuverlässig ist oder Events kritisch sind, plane Webhook + Polling.
• Wenn die API stark rate-limitiert ist, bevorzuge Webhooks plus leichtes Polling.
• Wenn Datenvolumen hoch ist, vermeide häufige Voll-Polls.

Bevor du dich festlegst, frag den Anbieter ein paar Dinge und bekomme klare Antworten:

• Welche Event-Typen gibt es und sind sie vollständig (create, update, delete)?
• Retryen sie Webhooks und wie lange?
• Kannst du Events erneut abspielen oder eine Event-Historie nach Zeitbereich abrufen?
• Signieren sie Webhook-Requests, sodass du die Authentizität verifizieren kannst?
• Unterstützen sie "updated since"-Abfragen für effizientes Polling?

Schritt-für-Schritt: eine Sync entwerfen, die korrekt bleibt

Eine "korrekte" Sync ist nicht nur "Daten erscheinen". Sie bedeutet, dass die richtigen Datensätze übereinstimmen, die neueste Änderung gewinnt und du nach Problemen nachweisen kannst, was passiert ist.

Beginne mit einem Plan, den du testen und überwachen kannst:

1. Definiere die Quelle der Wahrheit und die Regeln. Wähle, welches System welches Feld besitzt. Zum Beispiel: das CRM besitzt den Kundennamen, dein Billing-Tool besitzt den Subscription-Status. Entscheide, was "frisch genug" bedeutet (z. B. "innerhalb von 5 Minuten") und welche Fehler tolerierbar sind.
2. Wähle stabile Identifikatoren. Speichere die eindeutige ID des Drittanbieters neben deiner internen ID. Vermeide E-Mail oder Name als Schlüssel (sie ändern sich). Falls verfügbar, speichere eine Version oder ein "updated_at"-Zeitstempel, um neuere Daten zu erkennen.
3. Plane Initial-Import und danach inkrementelle Updates. Behandle den ersten Import als separaten Job mit Checkpoints, damit du fortsetzen kannst. Danach verarbeite nur Änderungen (Events, "since"-Abfragen oder beides) und speichere einen Cursor wie "last successful sync time".
4. Handle Deletes und Merges bewusst. Entscheide, ob Deletes den Datensatz entfernen, archivieren oder als inaktiv markieren. Bei Merges wähle, welche ID überlebt, und halte eine Audit-Spur.
5. Setze Monitoring-Signale. Messe Sync-Lag, fehlgeschlagene Calls und eine feststeckende Queue. Alarmiere, wenn Lag deinen Schwellwert überschreitet, nicht nur wenn etwas abstürzt.

Wenn du das implementierst, halte die Entscheidungen sichtbar in deinem Datenmodell: externe IDs, Zeitstempel, Statusfelder und ein Feld für Sync-Checkpoints. Diese Struktur hält die Sync korrekt, wenn die reale Welt chaotisch wird.

Idempotenz und Reihenfolge: der Kern verlässlicher Integrationen

Wenn du lange genug Webhooks vs Polling-Integrationen baust, taucht eine Regel immer wieder auf: du wirst Duplikate, Retries und außer-Reihenfolge-Updates sehen. Wenn dein Sync die gleiche Nachricht nicht sicher erneut verarbeiten kann, driftet er mit der Zeit auseinander.

Idempotenz bedeutet: "gleiche Eingabe, gleiches Ergebnis", selbst wenn sie zweimal ankommt. Behandle jedes eingehende Event als "vielleicht wiederholt" und gestalte deinen Handler sicher. Ein gängiges Muster ist: berechne einen Dedup-Key, prüfe, ob du ihn schon verarbeitet hast, und wende dann Änderungen an.

Dedup-Keys haben Kompromisse. Eine Event-ID ist ideal, wenn der Provider eine liefert. Wenn nicht, kannst du eine Objekt-Version (z. B. inkrementelle Revision) nutzen. Zeitfenster wie "Wiederholungen für 10 Minuten ignorieren" sind fragil, weil späte Ankünfte vorkommen.

Reihenfolge ist die andere Hälfte. Globale Reihenfolge ist selten, also ziele auf pro-Objekt-Reihenfolge. Wende Updates auf ein einzelnes Ticket, eine Rechnung oder einen Kunden nur an, wenn die Version neuer ist als das, was du gespeichert hast. Wenn du keine Version hast, nutze Last-Write-Wins mit einer klaren Regel (z. B. neueres updated_at gewinnt) und akzeptiere, dass Uhrabweichungen Randfälle verursachen können.

Speichere genug, um wiederherstellen und replayen zu können, ohne raten zu müssen:

• Eine pro-Objekt "last seen"-Version oder updated_at
• Einen zuletzt verarbeiteten Cursor oder Checkpoint für Polling-Jobs
• Eine Tabelle verarbeiteter Event-IDs (mit einer Retentionsregel, falls sie schnell wächst)
• Die Roh-Payload für einen kurzen Zeitraum, damit du Fixes erneut ausführen kannst

Beispiel: Ein Stripe-Payment-Webhook kommt zweimal an, dann ein "paid"-Update vor dem "created"-Event. Wenn du die neueste Status-Version der Rechnung speicherst und ältere Updates ignorierst, kommst du zum korrekten Ergebnis.

Retry- und Replay-Muster, die stillen Daten-Drift verhindern

Die meisten Integrationen scheitern still. Ein Webhook kommt spät, ein Polling-Job trifft ein Limit oder deine App timet beim Speichern aus. Ohne Retries und Replay weichen Systeme langsam voneinander ab, bis ein Kunde sich beschwert.

Webhook-Retries: schnell akzeptieren, sicher verarbeiten

Provider retryen normalerweise, wenn du nicht schnell genug einen erfolgreichen HTTP-Code zurückgibst. Behandle die Webhook-Anfrage als Lieferbenachrichtigung, nicht als Ort für schwere Arbeit.

Ein praktikables Webhook-Muster:

• Antworte schnell mit 2xx nach grundsätzlicher Validierung (Signatur, Schema, Zeitstempel).
• Speichere das Event mit einer eindeutigen ID und markiere es als pending.
• Verarbeite asynchron mit einem Worker und verfolge Versuche.
• Bei temporären Fehlern später erneut versuchen. Bei permanenten Fehlern stoppen und alarmieren.
• Verwende 4xx für fehlerhafte Daten und 5xx nur für echte Serverprobleme.

Das vermeidet die häufige Falle: anzunehmen, "Webhook empfangen" bedeutet "Daten sind synchronisiert".

Polling-Retries: höflich zur API sein

Polling versagt anders. Das Risiko ist ein Thundering-Herd an Retries nach einem kurzen Ausfall, was Limits verschlimmert. Nutze exponentielles Backoff plus Jitter und behalte einen "since"-Cursor, damit du nicht alles neu scannst.

Wenn du etwas jetzt nicht verarbeiten kannst, lege es in eine Dead-Letter-Queue (oder Tabelle) mit dem Grund. Das gibt dir einen sicheren Ort zum Inspizieren, Mapping-Regeln-Anpassen und erneuten Ausführen ohne Rätselraten.

Replay ist, wie du nach verpassten Events heilst. Eine einfache Replay-Strategie:

• Wähle ein Zeitfenster (z. B. letzte 24 Stunden) oder eine Menge betroffener Datensätze.
• Hole den aktuellen Zustand beim Provider erneut.
• Wende Updates idempotent an und korrigiere Abweichungen.
• Protokolliere, was sich geändert hat und warum.

Beispiel: Dein Billing-Provider sendet "invoice.paid", aber deine Datenbank war 30 Sekunden gesperrt. Du legst das Event in die Dead-Letter-Queue und replayst, indem du die Rechnung und Zahlungsstatus erneut abfragst und deine Datensätze abgleichst.

Häufige Fehler und wie man sie vermeidet

Die meisten Sync-Bugs sind keine großen Architekturprobleme. Es sind kleine Annahmen, die in stillen Drift, doppelte Datensätze oder verpasste Updates münden.

Einige, die immer wieder auftauchen:

• Zu oft pollen ohne inkrementelle Filter. Verfolge einen Cursor (updated_at, Event-ID, Page-Token) und frage nur nach Änderungen seit dem letzten erfolgreichen Lauf.
• Webhooks als garantierte Zustellung ansehen. Halte einen Backfill-Job, der die jüngste Historie (z. B. 24–72 Stunden) nachprüft und alles nachzieht, was fehlt.
• Duplikate ignorieren. Mache jeden Schreibvorgang idempotent. Speichere die Provider-Event-ID (oder eine stabile externe ID) und weigere dich, dieselbe Änderung zweimal anzuwenden.
• Webhook-Calls ohne Verifikation annehmen. Validier den Signatur-Token oder die vom Anbieter angebotene Verifikationsmethode.
• Blind auf Sync-Gesundheit sein. Messe Lag, Backlog-Größe, letzten erfolgreichen Lauf und Fehlerquoten. Alarmiere, wenn Lag einen Schwellenwert überschreitet.

Viele Debatten über "Webhooks vs Polling" verfehlen den Punkt: Zuverlässigkeit entsteht durch Sicherheitsvorkehrungen um beide Methoden. Ein Payment-Webhook kann doppelt oder verspätet kommen. Wenn dein System Records direkt beim Webhook ohne Idempotenz erstellt, kannst du Kunden doppelt benachrichtigen oder belasten.

Schnell-Checkliste für eine gesunde Integration

Tägliche Gesundheitschecks ähneln sich, egal ob du Webhooks, Polling oder beides nutzt. Du willst wissen, ob Daten frisch sind, ob Fehler sich anhäufen und ob du sauber wiederherstellen kannst.

Eine kurze Checkliste, die du in wenigen Minuten durchlaufen kannst:

• Aktualität: Vergleiche "letztes Event empfangen" oder "letzter Poll abgeschlossen" mit deinem erwarteten Lag.
• Fehler: Suche nach steigenden Retry-Zahlen oder Jobs, die sich nicht bewegt haben. Paar Fehlerzähler mit einem "last success"-Zeitstempel.
• Kontingente: Prüfe, wie viele API-Calls du verbraucht hast und was übrig ist. Wenn du nahe am Limit bist, verlangsame Polling und batche Anfragen.
• Korrektheit: Stichproben anstellen (z. B. "Bestellungen heute") und einige aktuelle Datensätze prüfen.
• Wiederherstellungsbereitschaft: Bestätige, dass du ein jüngeres Fenster sicher erneut verarbeiten kannst, ohne Duplikate oder fehlende Updates.

Eine nützliche Gewohnheit ist, gelegentlich eine bekannte stark belastete Periode kontrolliert zu replayen und die Ergebnisse mit der Produktion abzugleichen.

Beispiel: Webhooks und Polling für einen realistischen Workflow mischen

Stell dir ein kleines SaaS-Team vor, das drei Systeme synchron halten muss: ein CRM (Kontakte und Deals), Stripe-Zahlungen (Charges und Refunds) und ein Support-Tool (Ticket-Status).

Sie nutzen Webhooks-first für alles, was schnelle Reaktionen braucht. CRM-Events aktualisieren den Kunden-Datensatz und lösen interne Tasks aus. Stripe-Webhooks erstellen Rechnungen, schalten Features nach Zahlung frei und markieren Konten bei fehlgeschlagenen Zahlungen als überfällig. Für das Support-Tool nutzen sie Webhooks, falls verfügbar, halten aber auch einen geplanten Poll, weil Ticket-Status sich oft bulk-weise ändern.

Sie sehen Polling als Sicherheitsnetz, nicht als Hauptmotor. Jede Nacht läuft ein Reconciliation-Job, der die letzten 24 Stunden Änderungen aus den Systemen holt und mit dem abgleicht, was die App gespeichert hat.

Dann passiert ein realer Ausfall: ihr Webhook-Endpoint ist während eines Deployments 20 Minuten down.

• CRM und Stripe retryen die Zustellung für eine Weile.
• Einige Events kommen verspätet, einige außer Reihenfolge, einige können verfallen.
• Der Reconciliation-Poll erkennt eine Lücke (fehlende Event-IDs oder abweichende Summen) und füllt die Änderungen nach.

Was sie loggen: eingehende Event-ID, Provider-Zeitstempel, interne Record-ID und das Endergebnis (erstellt, aktualisiert, ignoriert). Was einen Alarm auslöst: wiederholte Webhook-Fehler, ein Anstieg der Retries oder die Reconciliation, die mehr als eine kleine Schwelle an fehlenden Updates findet.

Nächste Schritte: implementieren, überwachen und iterieren

Ein praktischer Default für die meisten Teams ist einfach: Nutze Webhooks für Unmittelbarkeit und halte einen kleinen Polling-Job zur Reconciliation. Webhooks bringen Änderungen schnell. Polling fängt das auf, was du wegen Ausfällen, falsch konfigurierter Subscriptions oder gelegentlich fallengelassener Events verpasst hast.

Mach die Sync korrekt, bevor du sie schnell machst. Behandle jede eingehende Änderung so, dass du sie sicher mehr als einmal anwenden kannst.

Drei erste Maßnahmen:

• Mappe die Events und Felder des Providers auf dein internes Modell, inkl. was "delete", "refund" oder "status change" für dich bedeutet.
• Entwirf Idempotenz von Anfang an: speichere eine externe Event-ID oder Version und mache jedes Update sicher wiederholbar, ohne Duplikate zu erzeugen.
• Baue Replay bewusst ein: halte einen "since last seen"-Cursor oder Zeitfenster-Poll bereit und ein Admin-Tool, um einen Bereich erneut auszuführen, wenn etwas nicht stimmt.

Sobald es läuft, ist Monitoring das, was es am Laufen hält. Verfolge Webhook-Delivery-Rate, Fehler nach Grund (Timeouts, 4xx, 5xx) und wie weit dein Reconciliation-Poll hinterherhinkt. Alarmiere bei "keine Events empfangen" sowie bei "zu vielen Events empfangen".

Wenn du diese Lösung lieber nicht komplett handschriftlich bauen willst, ist AppMaster (appmaster.io) eine No-Code-Option, mit der du Daten modellieren, Webhook-Endpunkte erstellen und Retry/Replay-Flows visuell entwerfen kannst, während trotzdem echter Quellcode für die Bereitstellung generiert wird.