Echtzeit oder Batch? Warum die meisten Automatisierungen keine Echtzeit brauchen
Echtzeit ist der Reflex, selten die Anforderung. Warum Batch in den meisten Workflows billiger und robuster läuft, plus die eine Frage, die wir vor jedem Trigger stellen.
"Das muss in Echtzeit laufen", sagte der Kunde. Es musste nicht.
Ein Vertriebsleiter aus Hamburg bestand letztes Jahr darauf, dass die Lead-Synchronisation zwischen Formular und CRM in Echtzeit passieren müsse. Sekunde für Sekunde, sofort. Wir haben eine einzige Frage gestellt: Wer schaut auf diese Leads, und wann? Antwort: das Vertriebsteam, einmal morgens und einmal nach dem Mittagessen.
Ein Webhook feuerte also den ganzen Tag hunderte Male, um ein System zu füttern, das jemand zwei Mal am Tag öffnete. Wir haben das auf einen Batch alle zwei Stunden umgestellt. Die Rechnung sank, die Duplikate verschwanden, und kein Mensch hat den Unterschied bemerkt.
Echtzeit ist der Reflex. Selten ist sie die Anforderung.
Warum jeder zuerst an Echtzeit denkt
"Sofort" klingt besser als "alle zwei Stunden". Echtzeit fühlt sich modern und professionell an, und die Werkzeuge verstärken das Gefühl. Make, n8n und Zapier behandeln Webhooks als erste Klasse, der Trigger ist das Erste, was man im Editor sieht. Der Default schiebt einen in Richtung ereignisgesteuert, noch bevor man über die eigentliche Anforderung nachgedacht hat.
Dabei ist "instant" in den meisten internen Prozessen ein Feature, nach dem niemand gefragt hat. Eine Rechnung, die um 9:00 Uhr statt um 8:58 Uhr im DATEV landet, ändert nichts. Ein Report, der zur vollen Stunde kommt statt in der Sekunde des Ereignisses, ändert nichts.
Wann braucht ein Prozess wirklich Echtzeit? Dann, wenn ein Mensch oder ein System innerhalb von Sekunden auf das Ereignis reagiert und die Verzögerung echte Kosten verursacht. Betrugserkennung beim Bezahlvorgang, Verfügbarkeitsanzeige im Shop, eine Bestätigung, auf die der Kunde gerade wartet. Alles andere verträgt Minuten oder Stunden, ohne dass es jemandem auffällt.
Was Echtzeit tatsächlich kostet
Echtzeit ist nicht gratis. Sie verschiebt die Kosten nur an eine Stelle, die man auf den ersten Blick nicht sieht.
Mehr Ausführungen heißt mehr Geld. Make rechnet pro Operation, Zapier pro Task. Ein Webhook, der 500 Mal am Tag feuert, kostet 500 Mal. Derselbe Job als Batch alle zwei Stunden kostet zwölf Mal. Bei einem Kunden mit drei solcher Synchronisationen war das der Unterschied zwischen dem Core- und dem Pro-Plan, ohne dass irgendjemand einen Nutzen der Echtzeit benennen konnte.
Mehr Auslösungen heißt mehr Fehlerpunkte. Ein Workflow, der 500 Mal pro Tag läuft, hat 500 Gelegenheiten zu scheitern, oft einzeln und unbemerkt. Ein Batch läuft zwölf Mal, scheitert sichtbar und lässt sich sauber wiederholen. Bei Echtzeit jagen Sie verstreuten Einzelfehlern hinterher, bei Batch sehen Sie das Problem an einer Stelle.
Echtzeit ist schwerer zu debuggen. Ereignisse kommen in unvorhersehbarer Reihenfolge, manchmal doppelt, manchmal überlappend. Ein Batch arbeitet einen sauberen Schnappschuss ab. Was um 10:00 Uhr in der Tabelle steht, wird verarbeitet, fertig. Diese Vorhersehbarkeit ist im Betrieb viel wert, vor allem wenn nachts um zwei etwas hakt.
Und dann die Rate Limits. Echtzeit-Workflows hämmern fremde APIs im Takt der Ereignisse. Kommen 50 Leads in einer Minute, gehen 50 Anfragen raus, und die API antwortet irgendwann mit einem 429. Ein Batch kann sich selbst takten und die Anfragen über die Zeit verteilen.
Wann Batch die bessere Wahl ist
Die ehrliche Faustregel: Wenn der Empfänger ein Mensch ist, der periodisch nachschaut, oder ein System, das ohnehin nach eigenem Zeitplan läuft, ist Batch fast immer richtig.
Reports, die jemand morgens liest. CRM-Synchronisationen, auf die ein Team zwei Mal am Tag schaut. Datenexporte ins Warehouse, das nachts ohnehin neu rechnet. Newsletter-Listen, die einmal täglich aktualisiert werden. Rechnungsexporte, die der Steuerberater am Monatsende abruft. In all diesen Fällen kauft Echtzeit nichts, kostet aber.
Der Mittelweg, den die meisten übersehen
Die Entscheidung ist nicht binär. Zwischen "sofort bei jedem Ereignis" und "einmal am Tag" liegt Micro-Batching, und das ist oft die beste Antwort.
Die Idee: Ereignisse werden in Echtzeit eingesammelt, aber nicht sofort einzeln verarbeitet. Sie landen in einer Warteschlange oder einer Tabelle, und ein Workflow arbeitet sie alle fünf oder zehn Minuten gebündelt ab. Für den Nutzer fühlt es sich praktisch wie Echtzeit an, im Betrieb hat es die Robustheit eines Batches. Sie sammeln 30 Leads in zehn Minuten und verarbeiten sie in einem Lauf, mit einem API-Call statt dreißig.
Wir bauen das inzwischen als Standardmuster für alles, was nach Echtzeit aussieht, aber keine Echtzeit braucht. Es ist der Kompromiss, der in der Praxis am seltensten falsch ist.
Die Frage, die wir vor jedem Trigger stellen
Bevor wir einen Workflow auf einen Echtzeit-Trigger setzen, beantworten wir genau eine Frage: Wer reagiert auf dieses Ereignis, und wie schnell muss er es?
Lautet die Antwort "ein Mensch, zwei Mal am Tag", wird es ein Batch. Lautet sie "ein System, innerhalb von Sekunden, und jede Verzögerung kostet", wird es Echtzeit. In den allermeisten Fällen, die uns begegnen, ist es das Erste.
Echtzeit sieht in der Demo gut aus und wird im Betrieb teuer. Bevor Sie den Webhook bauen, fragen Sie, ob überhaupt jemand auf die Sekunde wartet. Meistens wartet niemand.
Falls Sie unsicher sind, welche Ihrer Workflows echte Echtzeit brauchen und welche nur aus Gewohnheit in Echtzeit laufen, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir gehen die Trigger gemeinsam durch und zeigen Ihnen, wo ein Batch die gleiche Wirkung für einen Bruchteil der Kosten hätte.