Warum jede ernsthafte Automatisierung eine Warteschlange braucht

Der Freitagabend, an dem der Shop schneller war als unsere Automatisierung

Ein Kunde von uns, ein Onlinehändler mit rund vierzig Mitarbeitern, startete an einem Freitag um 18 Uhr eine Rabattaktion. Newsletter raus, Anzeige geschaltet, und dann kam, was kommen sollte: Bestellungen. Sehr viele Bestellungen, sehr schnell. Der Shop hielt das aus, dafür war er gebaut. Die Automatisierung dahinter nicht.

Hinter jedem Kauf lief ein Ablauf in einer bekannten No-Code-Plattform. Bestellung entgegennehmen, Kundendaten ins CRM schreiben, Rechnung in der Buchhaltungssoftware anlegen, Lagerbestand aktualisieren, Bestätigung verschicken. An einem normalen Dienstag verarbeitete das ein paar Dutzend Bestellungen pro Stunde, sauber und unauffällig. An diesem Freitag trafen in den ersten zwanzig Minuten über tausend Bestellungen ein.

Was danach passierte, sah ich am Montag in den Logs. Die Buchhaltungs-API hatte nach etwa dreihundert Aufrufen mit einem Rate Limit dichtgemacht. Ab da lieferte sie nur noch Fehler zurück. Der Workflow tat, was er gelernt hatte: Er versuchte es erneut, sofort, mit voller Wucht, was die API noch länger blockierte. Ein Teil der Bestellungen landete gar nicht im CRM. Ein anderer Teil landete doppelt, weil ein halb durchgelaufener Ablauf neu gestartet wurde. Und einige Kunden bekamen ihre Bestätigung erst am Samstagnachmittag, weil die Plattform die aufgestauten Durchläufe stundenlang nacharbeitete.

Am Ende des Wochenendes stand der Kunde vor drei Sorten Schaden. Verlorene Bestellungen, die er nur fand, weil ein paar Käufer nachfragten, wo ihre Ware bleibe. Doppelte Rechnungen, die seine Buchhalterin am Montag von Hand aussortieren musste. Und ein Stapel verspäteter Bestätigungen, der bei einigen Kunden den Eindruck hinterließ, der Laden habe sein Geschäft nicht im Griff. Der Umsatz der Aktion war da, aber ein Teil des Vertrauens war beschädigt, und Vertrauen ist im Onlinehandel die eigentliche Währung.

Der Shop hatte alles richtig gemacht. Die Automatisierung hatte einen strukturellen Fehler, und der Fehler hat einen Namen. Zwischen dem Ereignis und seiner Verarbeitung fehlte eine Warteschlange.

Was eine Warteschlange ist und warum Automatisierung nicht dasselbe ist

Die meisten Automatisierungen, die ich in Betrieben sehe, sind synchron gebaut. Ein Ereignis kommt herein, und derselbe Ablauf, der es entgegennimmt, erledigt auch gleich die ganze Arbeit: schreiben, rechnen, verschicken. Entgegennahme und Verarbeitung sind eins. Das funktioniert, solange die Ereignisse einzeln und in gemütlichem Abstand eintreffen.

Eine Warteschlange trennt diese beiden Dinge. Vorne steht eine Stelle, die Ereignisse nur entgegennimmt und ablegt, sonst nichts. Das geht schnell, weil kaum Arbeit anfällt. Hinten steht ein zweiter Ablauf, der sich die abgelegten Ereignisse in seinem eigenen Tempo holt und abarbeitet. Zwischen beiden liegt der Puffer, die eigentliche Warteschlange. Sie hält fest, was noch nicht dran war.

In der Fachsprache heißen die beiden Seiten Producer und Consumer. Der Producer erzeugt Aufgaben und legt sie ab. Der Consumer nimmt sie heraus und erledigt sie. Der Punkt ist, dass beide unabhängig voneinander laufen. Wenn tausend Bestellungen in zwanzig Minuten eintreffen, nimmt der Producer sie in Sekunden entgegen und legt sie in die Warteschlange. Der Consumer arbeitet sie danach im Takt ab, den die langsamste beteiligte API vorgibt. Nichts geht verloren, nichts überrennt ein nachgelagertes System.

Der Unterschied zwischen sofort verarbeiten und sicher entgegennehmen

Der teuerste Denkfehler in der Prozessautomatisierung ist die Gleichsetzung von schnell und sofort. Ein Kunde erwartet, dass seine Bestellung sofort ankommt. Er erwartet nicht, dass seine Rechnung in derselben Sekunde in der Buchhaltung steht. Diese beiden Erwartungen darf man trennen, und genau das tut eine Warteschlange.

Sicher entgegennehmen heißt: Das Ereignis ist festgehalten, es kann nicht mehr verloren gehen, der Absender bekommt sofort eine Bestätigung. Ob die eigentliche Arbeit zwei Sekunden oder zwei Minuten später passiert, merkt niemand. Was Kunden dagegen sehr wohl merken, ist eine verlorene Bestellung. Wer diesen Unterschied einmal verstanden hat, baut Automatisierungen anders.

Eine Warteschlange kauft Ihnen also Zeit und Sicherheit, ohne dass der Absender davon etwas spürt.

Woran Sie erkennen, dass Ihnen eine Warteschlange fehlt

Die Frage bekomme ich in Erstgesprächen oft: Woran merke ich, dass ich eine Warteschlange brauche und nicht bloß eine bessere Automatisierung? Die kurze Antwort: an drei Situationen, in denen synchrone Abläufe zuverlässig zerbrechen. Wenn Ihr Betrieb eine davon kennt, ist die Warteschlange keine Spielerei, sondern die günstigste Versicherung, die Sie kaufen können.

Lastspitzen

Das offensichtliche Muster ist die Spitze. Rabattaktion, Messe, ein Beitrag geht viral, Monatsabschluss, Feiertagsgeschäft. Ereignisse kommen nicht gleichmäßig, sondern in Wellen. Ein synchroner Ablauf verarbeitet die Welle so schnell, wie das schwächste Glied in der Kette mitkommt, und das schwächste Glied ist fast immer eine fremde API mit einem Rate Limit. Über dieses Thema habe ich an anderer Stelle geschrieben, als es um die Fehlermeldung 429 ging. Die Warteschlange ist die saubere Antwort darauf: Sie nimmt die ganze Welle sofort auf und lässt den Consumer sie im erlaubten Tempo abtragen.

Wenn ein nachgelagertes System langsam oder offline ist

Jedes System, das Sie nicht selbst betreiben, wird irgendwann nicht erreichbar sein. Die Buchhaltungssoftware hat ein Wartungsfenster, das CRM hat eine Störung, die Rechnungs-API antwortet für vierzig Minuten mit Fehlern. In einem synchronen Ablauf bedeutet das: Alles, was in diesen vierzig Minuten passiert, schlägt fehl. Bei einer Warteschlange bedeutet es: Die Ereignisse stapeln sich geduldig im Puffer, und sobald das System zurück ist, arbeitet der Consumer den Stapel ab. Der Ausfall wird zur Verzögerung statt zum Datenverlust. Das ist ein gewaltiger Unterschied, und er entscheidet sich an dieser einen Architekturfrage.

Wenn die Reihenfolge zählt

Manchmal dürfen zwei Ereignisse zum selben Datensatz nicht gleichzeitig verarbeitet werden. Ein Kunde ändert seine Adresse und storniert eine Sekunde später. Laufen beide Abläufe parallel, gewinnt der schnellere, und welcher das ist, hängt vom Zufall ab. Eine Warteschlange kann Ereignisse in der Reihenfolge halten, in der sie eintrafen, und sie nacheinander abarbeiten. Damit verschwindet eine ganze Klasse von Fehlern, die sich sonst nur sporadisch zeigt und deshalb kaum zu finden ist.

Lastspitzen, Ausfälle nachgelagerter Systeme und Reihenfolgeprobleme sind die Symptome. Wer eines davon regelmäßig erlebt, hat kein Tool-Problem, sondern ein Architekturproblem.

Was die No-Code-Plattformen wirklich können

Jetzt kommt der Teil, bei dem ich mir keine Freunde mache. Die verbreiteten No-Code-Plattformen werben gern mit Zuverlässigkeit und Fehlerbehandlung, aber eine echte Warteschlange, die diesen Namen verdient, hat kaum eine von Haus aus. Man muss genau hinsehen, was jeweils gemeint ist.

Make und Zapier: die eingebaute Warteschlange ist keine

Make hat eine interne Verarbeitungsreihenfolge und kann Durchläufe bei Fehlern in einen Wiederholungsmodus schicken. Zapier hat einen Autoreplay und für manche Pläne eine Verzögerungsfunktion. Das klingt nach Warteschlange, verhält sich aber nicht so. Diese Mechanismen sind für den Einzelfehler gedacht, nicht für die Welle. Kommen tausend Ereignisse gleichzeitig, feuern beide Plattformen weiterhin so viele Durchläufe wie möglich gegen das nachgelagerte System, weil ihr Grundmodell darin besteht, jeden Trigger möglichst sofort abzuarbeiten. Die Entkopplung, um die es bei einer Warteschlange geht, findet nicht statt.

Man kann sich mit Bordmitteln behelfen. Ein häufiger Trick ist, eingehende Ereignisse zuerst in eine Tabelle oder einen Datastore zu schreiben und einen zweiten, zeitgesteuerten Ablauf im Minutentakt die neuen Zeilen abarbeiten zu lassen. Das ist tatsächlich eine selbstgebaute Warteschlange, und für viele Betriebe reicht sie vollkommen. Nur sollte man wissen, dass man sie selbst baut und pflegt, statt sie zu kaufen.

n8n Queue Mode: die ehrlichste Option im No-Code-Lager

n8n hat als einzige der großen Plattformen einen echten Queue Mode eingebaut. Dabei laufen die Workflows nicht mehr im selben Prozess, der sie auslöst, sondern werden über eine Redis-Warteschlange an mehrere Worker verteilt. Das ist genau das Producer-Consumer-Modell, nur ohne dass man es von Hand nachbauen muss. Wer n8n selbst hostet und ernsthaft Last verarbeitet, sollte diesen Modus nutzen. Über die Realität des Selbst-Hostens von n8n habe ich getrennt geschrieben, denn kostenlos im Wortsinn ist auch das nicht.

Ein praktischer Hinweis dazu: Der Queue Mode ist im Standard nicht aktiv, man muss ihn bewusst einschalten und dafür einen Redis daneben betreiben. Viele n8n-Installationen, die ich mir ansehe, laufen im einfachen Modus und stoßen bei der ersten größeren Last an dieselbe Wand wie Make oder Zapier, obwohl die Lösung schon im Werkzeug steckt. Es lohnt sich, diesen Schalter zu kennen, bevor man ihn im Ausfall zum ersten Mal sucht.

Hier eine nüchterne Gegenüberstellung, wie ich sie in Projekten verwende:

No-Code nimmt Ihnen den Bau vieler Dinge ab, aber die Warteschlange gehört bei den meisten Plattformen nicht dazu. Entweder Sie bauen sie sich, oder Sie wählen ein Werkzeug, das sie mitbringt.

Die Begriffe, an denen sich Projekte entscheiden

Sobald man eine Warteschlange einführt, tauchen drei Begriffe auf, die man verstanden haben muss, bevor man sie in Betrieb nimmt. Wer sie überspringt, baut sich neue Probleme, die schwerer zu finden sind als die alten.

At-least-once heißt: bauen Sie idempotent

Fast alle praktikablen Warteschlangen garantieren eine Zustellung mindestens einmal, nicht genau einmal. Das bedeutet: In seltenen Fällen wird derselbe Auftrag zweimal aus der Warteschlange geholt, etwa wenn ein Consumer mitten in der Arbeit abstürzt und der Auftrag nach einer Weile wieder freigegeben wird. Für Sie heißt das, dass der verarbeitende Ablauf mit einer doppelten Zustellung umgehen können muss, ohne Schaden anzurichten. Eine Rechnung darf nicht zweimal entstehen, nur weil ihr Auslöser zweimal ankam.

Die Lösung dafür ist Idempotenz, ein Prinzip, dem ich einen eigenen Beitrag gewidmet habe. Kurz gesagt prüft der Consumer vor dem Handeln, ob diese konkrete Aufgabe schon erledigt wurde, meist über eine eindeutige Kennung des Ereignisses. Ist sie erledigt, wird sie stillschweigend übersprungen. Wer eine Warteschlange einführt und die Idempotenz vergisst, tauscht verlorene Datensätze gegen doppelte ein, und doppelte sind oft der teurere Fehler.

An dieser Stelle fragen mich Kunden regelmäßig: Warum garantiert die Warteschlange nicht einfach genau eine Zustellung, dann hätte man das Problem doch gar nicht? Die ehrliche Antwort ist, dass exactly-once über Systemgrenzen hinweg praktisch nicht existiert. Sobald der Consumer eine fremde API aufruft und dabei die Verbindung abreißt, weiß er nicht, ob die API die Aufgabe ausgeführt hat oder nicht. Er kann nur entscheiden, ob er im Zweifel noch einmal zustellt, was ein Duplikat riskiert, oder nicht mehr zustellt, was einen Verlust riskiert. Fast alle ernsthaften Systeme wählen die Wiederholung und schieben die Verantwortung für das Erkennen von Duplikaten zum Empfänger. Deshalb ist Idempotenz keine Kür, sondern die zwingende Kehrseite jeder Warteschlange.

Dead Letter Queue: der Ort für das, was dauerhaft scheitert

Manche Aufgaben lassen sich nicht verarbeiten, egal wie oft man es versucht. Ein kaputter Datensatz, ein Sonderzeichen, das die Ziel-API nicht verträgt, eine Bestellung zu einem Produkt, das es nicht mehr gibt. Wenn der Consumer so etwas immer wieder aus der Warteschlange holt, daran scheitert und es zurücklegt, entsteht eine Endlosschleife, die die ganze Warteschlange blockiert. Diese Falle habe ich in einem anderen Beitrag über Trigger-Schleifen beschrieben.

Die Antwort heißt Dead Letter Queue, zu Deutsch etwa Warteschlange für unzustellbare Nachrichten. Nach einer festgelegten Zahl von Fehlversuchen, meist drei bis fünf, wandert die Aufgabe nicht zurück in die Hauptwarteschlange, sondern in einen separaten Ablage-Ort. Dort liegt sie sicher, blockiert nichts mehr, und ein Mensch kann sie sich in Ruhe ansehen. Eine Warteschlange ohne diesen Auffang-Ort ist ein Kartenhaus, das beim ersten kaputten Datensatz einstürzt.

Sichtbarkeit: eine Warteschlange, in die niemand sieht, ist gefährlich

Der dritte Begriff ist weniger technisch, aber wichtiger, als die meisten glauben. Eine Warteschlange versteckt Verzögerungen, das ist ihr Sinn. Genau das macht sie tückisch, wenn niemand hinsieht. Wenn der Consumer langsamer arbeitet, als der Producer nachliefert, wächst der Puffer, und zwar unbemerkt, bis er irgendwann Stunden an Rückstand enthält. Sie brauchen eine einzige Zahl auf einem Dashboard: wie viele Aufgaben warten gerade. Steigt diese Zahl über einen Schwellenwert und sinkt nicht wieder, ist etwas kaputt. Ohne diese Zahl merken Sie den Stau erst, wenn ein Kunde anruft.

At-least-once zwingt Sie zur Idempotenz, die Dead Letter Queue rettet Sie vor dem kaputten Datensatz, und die Sichtbarkeit rettet Sie vor dem stillen Rückstau. Die drei gehören zusammen und sind kein Zubehör.

So bauen Sie eine belastbare Warteschlange mit Bordmitteln

Die meisten Leser dieses Beitrags werden keine verwaltete Cloud-Queue aufsetzen, sondern eine Warteschlange mit den Werkzeugen bauen, die sie schon haben: einer Tabelle und einem zeitgesteuerten Ablauf. Das ist völlig in Ordnung, und wenn man ein paar Dinge richtig macht, hält so eine Lösung erstaunlich viel aus. Ich zeige den Bauplan so konkret, dass Sie ihn nachbauen können.

Der Speicher: eine Tabelle mit einem Statusfeld

Sie brauchen einen Ort, an dem eingehende Ereignisse liegen. Eine Tabelle in Airtable, ein Google Sheet, ein Datastore in Make, eine Datenbanktabelle, das spielt zunächst keine Rolle. Wichtig sind die Spalten. Jede Zeile ist eine Aufgabe und braucht mindestens: eine eindeutige Kennung des Ereignisses, den eigentlichen Inhalt als Datenfeld, ein Statusfeld, einen Zähler für die Fehlversuche und einen Zeitstempel der letzten Bearbeitung.

Das Statusfeld ist das Herz der Konstruktion. Es kennt vier Werte: offen, in Arbeit, erledigt und fehlgeschlagen. Eine neue Aufgabe kommt als offen herein. Nimmt der Consumer sie sich, setzt er sie auf in Arbeit. Klappt die Verarbeitung, wird sie erledigt. Scheitert sie endgültig, wird sie fehlgeschlagen. Diese vier Zustände klingen banal, aber an ihnen entscheidet sich, ob Ihre Warteschlange bei Last sauber bleibt oder Aufgaben doppelt verarbeitet.

Der Producer: schnell rein, sonst nichts

Der erste Ablauf ist der einfache. Er empfängt das Ereignis, etwa über einen Webhook, erzeugt die eindeutige Kennung, falls das Quellsystem keine mitliefert, und schreibt eine neue Zeile mit Status offen. Dann antwortet er dem Absender sofort. Keine Verarbeitung, keine API-Aufrufe zu langsamen Systemen, nichts, was ihn aufhalten könnte. Genau deshalb übersteht er jede Lastspitze. Er tut so wenig, dass tausend Aufrufe in kurzer Zeit ihn nicht ins Schwitzen bringen.

Ein Detail, das oft vergessen wird: Wenn das Quellsystem eine eigene Ereignis-Kennung mitschickt, verwenden Sie diese, statt selbst eine zu erzeugen. Schickt der Shop dieselbe Bestellung wegen eines Verbindungsproblems zweimal, landen zwei Zeilen mit derselben Kennung in der Tabelle. Wenn Sie beim Schreiben prüfen, ob die Kennung schon existiert, fangen Sie das Duplikat schon an der Eingangstür ab, bevor es überhaupt in die Warteschlange kommt.

Der Consumer: nehmen, sperren, arbeiten, quittieren

Der zweite Ablauf ist der interessante. Er läuft zeitgesteuert, etwa alle dreißig oder sechzig Sekunden, und arbeitet in vier Schritten. Erstens holt er sich eine begrenzte Zahl offener Zeilen, meist zehn bis fünfzig, nicht alle auf einmal. Zweitens setzt er sie sofort auf in Arbeit, bevor er irgendetwas verarbeitet. Dieser zweite Schritt ist die Sperre, und ohne sie funktioniert das Ganze nicht. Drittens verarbeitet er jede Zeile einzeln: CRM, Rechnung, was auch immer die Aufgabe verlangt. Viertens setzt er die Zeile bei Erfolg auf erledigt, bei Fehler erhöht er den Fehlerzähler und setzt sie zurück auf offen, damit der nächste Lauf es erneut versucht.

Warum die Sperre vor der Verarbeitung? Weil zwei Läufe des Consumers sich überschneiden können. Braucht ein Lauf länger als das Intervall, startet der nächste, während der erste noch arbeitet. Holen sich beide dieselben offenen Zeilen, wird jede Aufgabe doppelt verarbeitet. Setzt der Consumer die Zeilen aber sofort auf in Arbeit, bevor er loslegt, sieht der zweite Lauf sie nicht mehr als offen und lässt sie in Ruhe. Diese eine Regel verhindert die häufigste Ursache für Doppelverarbeitung in selbstgebauten Warteschlangen.

Der Fehlerpfad: der Zähler als Notausgang

Der Fehlerzähler ist Ihr Schutz vor der Endlosschleife. Jedes Mal, wenn eine Zeile scheitert, wird er um eins erhöht. Erreicht er einen Schwellenwert, üblicherweise drei bis fünf, setzt der Consumer die Zeile nicht mehr auf offen, sondern auf fehlgeschlagen, und schickt eine Meldung an einen Menschen. Damit haben Sie eine einfache Dead Letter Queue gebaut: Alle Zeilen mit Status fehlgeschlagen sind Ihr Ablage-Ort für das, was Aufmerksamkeit braucht. Eine kaputte Zeile blockiert nie wieder die ganze Warteschlange, weil sie nach wenigen Versuchen aus dem Weg geräumt wird.

Damit steht das Grundgerüst. Ein Producer, der nur entgegennimmt. Eine Tabelle mit vier Zuständen. Ein Consumer, der sperrt, arbeitet und quittiert. Ein Zähler, der Endlosschleifen beendet. Das sind vier überschaubare Bausteine, und zusammen ergeben sie eine Warteschlange, die den meisten Betrieben jahrelang treue Dienste leistet.

Die Fehler, die beim ersten Queue-Projekt fast garantiert passieren

Ich habe genug dieser Konstruktionen gesehen, die eigene inbegriffen, um die typischen Stolpersteine zu kennen. Wer sie vorher kennt, spart sich das Lehrgeld.

Der erste Fehler ist die fehlende Sperre. Ohne den Schritt, der Zeilen sofort auf in Arbeit setzt, funktioniert alles wunderbar, solange die Verarbeitung schneller ist als das Intervall. Sobald sie es einmal nicht ist, entstehen Doppel. Dieser Fehler zeigt sich nie im Test, weil im Test nie genug los ist, und immer im Produktivbetrieb an einem geschäftigen Tag.

Der zweite Fehler ist der fehlende Deckel für die Fehlversuche. Ohne Zähler wandert eine kaputte Zeile ewig zwischen offen und Fehler hin und her, verbraucht bei jedem Lauf einen Verarbeitungsplatz und schiebt gesunde Aufgaben nach hinten. Eine einzige kaputte Zeile kann so eine ganze Warteschlange lahmlegen.

Der dritte Fehler ist ein zu kurzes Intervall aus Ungeduld. Wer den Consumer alle fünf Sekunden laufen lässt, obwohl alle sechzig Sekunden genügen würden, verbrennt bei Make oder Zapier unnötig Operationen und damit Geld, ohne dass ein Kunde den Unterschied bemerkt. Die richtige Frage ist nicht, wie schnell die Warteschlange leer ist, sondern wie viel Verzögerung Ihr Prozess verträgt. Bei einer Rechnung sind zwei Minuten völlig gleichgültig.

Der vierte Fehler ist die fehlende Sichtbarkeit, die ich weiter oben schon angesprochen habe. Ohne eine Zahl, die den Rückstand zeigt, läuft ein wachsender Stau unbemerkt, bis er groß genug für einen Kundenanruf ist. Eine simple Zählung der offenen Zeilen auf einem Dashboard, dazu eine Meldung, wenn die Zahl einen Schwellenwert übersteigt, kostet eine Stunde Arbeit und erspart Ihnen den bösen Montag.

Der fünfte Fehler ist, den fehlgeschlagenen Zeilen keinen zweiten Blick zu schenken. Eine Dead Letter Queue ist nur so nützlich wie die Gewohnheit, sie regelmäßig durchzusehen. Ich habe Ablage-Orte gefunden, in denen sich über Monate stumme Fehler sammelten, ohne dass jemand hinsah, was den ganzen Aufwand der sauberen Fehlerbehandlung wieder zunichtemachte.

Drei Architekturen, die ich real gebaut habe

Theorie hilft nur bis zu einem Punkt. Hier sind drei Umsetzungen aus echten Projekten, in unterschiedlichen Betriebsgrößen, mit unterschiedlichen Mitteln.

Der Puffer vor dem CRM beim B2B-Händler

Zurück zum Onlinehändler vom Anfang. Wir haben den einen großen Ablauf in zwei zerlegt. Der erste nimmt die Bestellung entgegen, schreibt sie in eine simple Tabelle mit einem Statusfeld und antwortet dem Shop sofort mit einer Bestätigung. Mehr tut er nicht, und deshalb ist er in Sekundenbruchteilen fertig, egal wie viele Bestellungen kommen. Der zweite Ablauf läuft alle dreißig Sekunden, nimmt sich die nächsten zwanzig offenen Zeilen und verarbeitet sie: CRM, Buchhaltung, Lager, Bestätigung. Schlägt ein Schritt fehl, bleibt die Zeile offen und wird beim nächsten Lauf erneut versucht, bis zu fünfmal. Danach wird sie als Problemfall markiert und eine Meldung geht raus.

Diese Lösung ist mit Bordmitteln der bestehenden Plattform gebaut, ohne zusätzliche Infrastruktur. Der ganze Umbau kostete etwa zwei Tage Arbeit, das meiste davon Testen. Beim nächsten Aktionsfreitag trafen wieder über tausend Bestellungen in kurzer Zeit ein. Diesmal war um Mitternacht alles verarbeitet, sauber, ohne Doppelte, ohne Verluste. Der höchste Rückstand, den die Warteschlange zwischendurch aufwies, lag bei etwa vierzig Minuten, und in diesen vierzig Minuten hatte trotzdem jeder Kunde sofort seine Kaufbestätigung, weil die vom schnellen Producer kam und nicht vom langsamen Consumer. Der Kunde hat den Unterschied nicht gesehen, und das ist genau das Ziel.

Die Redis-Liste vor der Rechnungs-API im Solo-Betrieb

Ein Selbstständiger, der Onlinekurse verkauft, hatte ein anderes Problem in kleinerem Maßstab. Bei jedem Kursstart kamen innerhalb weniger Minuten hunderte Käufe herein, und seine Rechnungs-API erlaubte nur wenige Aufrufe pro Sekunde. Ein Tabellen-Puffer wäre gegangen, aber er hostete ohnehin einen kleinen Server, und dort lief bereits ein Redis. Also haben wir eine Redis-Liste als Warteschlange genutzt. Der Kauf-Webhook schiebt die Bestellung in die Liste, ein kleines Skript zieht sie im erlaubten Takt heraus und ruft die API auf.

Der Punkt an diesem Beispiel: Man muss nicht groß sein, um eine echte Warteschlange zu brauchen. Der Solo-Betrieb hatte dieselbe Lastspitze wie ein Konzern, nur in absoluten Zahlen kleiner. Die Architektur war dieselbe. Und der Aufwand war winzig: Das Skript, das die Liste abarbeitet, umfasst keine dreißig Zeilen, läuft in einem Container auf demselben kleinen Server und hat seit der Einrichtung keinen einzigen Kursstart mehr in die Knie gehen lassen. Bemerkenswert an dem Fall ist, dass er ohne No-Code-Plattform auskam, obwohl der Betrieb sonst stark auf solche Werkzeuge setzt. Manchmal ist die passende Antwort auf eine technische Frage schlicht ein kleines Stück Code an der richtigen Stelle.

Die verwaltete Queue im Konzern-Kontext

Im dritten Fall, einem größeren Unternehmen mit einer eigenen IT-Abteilung, kam eine Anforderung dazu, die es vorher nicht gab: Nachvollziehbarkeit und Betriebssicherheit mussten belegbar sein. Eine selbstgebaute Tabellen-Warteschlange hätte funktioniert, aber sie hätte niemand abgenommen, der für den Betrieb geradestehen muss. Also nutzten wir einen verwalteten Dienst des vorhandenen Cloud-Anbieters mit eingebauter Dead Letter Queue, garantierten Zustellungen und Metriken, die man in die bestehende Überwachung einhängen konnte. Der Aufwand war höher, die Kontrolle und die Prüfbarkeit aber auch.

Interessant war an diesem Projekt weniger die Technik als die Diskussion davor. Die Fachabteilung wollte zunächst dieselbe Tabellen-Lösung, die beim Händler so gut lief, weil sie sie verstand und selbst betreuen konnte. Die IT bestand auf dem verwalteten Dienst, weil sie im Störungsfall belastbare Metriken und ein Vier-Augen-Prinzip brauchte. Beide hatten recht, nur für unterschiedliche Zielgrößen. Am Ende entscheidet nicht die eleganteste Technik, sondern die Frage, wer nachts um drei den Rückstand abbaut, wenn etwas klemmt, und was diese Person dafür an Werkzeug in der Hand haben muss.

Dieselbe Grundidee, drei Umsetzungen, gestaffelt nach Anforderung. Vom Tabellen-Puffer über die Redis-Liste bis zur verwalteten Queue ist es kein Sprung, sondern eine Treppe.

Wann Sie keine Warteschlange brauchen

So überzeugt ich von Warteschlangen bin, so klar muss ich sagen: Die meisten Automatisierungen brauchen keine. Wenn ein Ereignis pro Stunde eintrifft, wenn keine Spitzen vorkommen, wenn ein gelegentlicher Fehlversuch ohne Folgen bleibt, dann ist eine Warteschlange überflüssige Technik, die Sie warten müssen, ohne einen Gegenwert zu bekommen. Ich habe an anderer Stelle über die Faustregel geschrieben, einen Vorgang erst einmal von Hand zu machen, bevor man ihn automatisiert. In derselben Haltung gilt: Bauen Sie die Warteschlange, wenn der synchrone Ablauf nachweislich an seine Grenze kommt, nicht vorher.

Das Anzeichen ist konkret und nicht schwer zu erkennen. Sie sehen in den Logs fehlgeschlagene Durchläufe, die mit Rate Limits, Zeitüberschreitungen oder überlaufenden Systemen zu tun haben, und diese Fehler häufen sich zu bestimmten Zeiten. Kommt das ein-, zweimal im Jahr vor und richtet keinen Schaden an, leben Sie damit. Kommt es jeden Monatsabschluss und kostet Sie Nacharbeit oder Kundenvertrauen, ist der Zeitpunkt da.

Was ich daraus gelernt habe

Die meisten teuren Ausfälle in Automatisierungen, die ich untersucht habe, waren keine Frage des falschen Tools. Sie waren die Folge einer einzigen Designentscheidung, die niemand bewusst getroffen hat: Entgegennahme und Verarbeitung wurden in einen Topf geworfen, weil es am Anfang, bei zehn Ereignissen am Tag, keinen Unterschied machte. Der Unterschied kommt später, mit dem Wachstum, mit der ersten Rabattaktion, mit dem ersten viralen Beitrag. Und er kommt an einem Freitagabend, wenn niemand hinschaut.

Das Beruhigende daran ist, dass die Lösung selten teuer oder kompliziert ist. Ein Producer, eine Tabelle mit vier Zuständen, ein Consumer mit Sperre und ein Fehlerzähler genügen den meisten Betrieben. Das ist keine Raketentechnik, sondern eine Denkweise: Nimm entgegen, was hereinkommt, und arbeite es in deinem eigenen Tempo ab.

Ich habe gelernt, bei jeder Automatisierung, die etwas Wichtiges verarbeitet, eine einzige Frage früh zu stellen: Was passiert, wenn hiervon plötzlich das Tausendfache kommt? Wenn die ehrliche Antwort lautet, dass dann Dinge verloren gehen oder doppelt entstehen, gehört eine Warteschlange dazwischen. Nicht, weil es modern klingt, sondern weil es der Unterschied zwischen einer Verzögerung und einem Schaden ist. Eine Verzögerung merkt am Montag niemand mehr. Einen Schaden merken alle.