Warteschlangen und asynchrone Verarbeitung

Nicht alles, was ein System tun muss, muss sofort passieren. Wenn jemand einen Termin bucht, braucht er sofort die Bestätigung, dass der Termin reserviert ist. Die Bestätigungs-E-Mail, die Aktualisierung der Statistik und die Benachrichtigung an den Salon können dagegen einige Sekunden später folgen. Warteschlangen – im Englischen Queues – machen genau diese Trennung möglich. Sie gehören zu den wichtigsten Bausteinen robuster Systeme, weil sie langsame, unzuverlässige oder rechenintensive Arbeit von den Anfragen entkoppeln, auf die Nutzer warten.

1. Synchron oder asynchron?

Die erste Frage im Entwurf lautet für jede Aufgabe: Muss der Nutzer auf das Ergebnis warten? Wenn ja, läuft sie synchron in der Anfrage. Wenn nein, kann sie asynchron im Hintergrund laufen. Asynchrone Verarbeitung hat mehrere Vorteile: Die Antwort an den Nutzer ist schneller, ein Ausfall eines externen Dienstes blockiert nicht den ganzen Vorgang, Lastspitzen werden abgefedert, und rechenintensive Arbeit läuft auf eigenen Servern. Üben Sie die Unterscheidung:

2. Produzent, Warteschlange, Worker

Das Prinzip ist einfach. Die Anwendung, der Produzent, legt einen Auftrag in die Warteschlange, etwa „sende Bestätigungs-E-Mail für Buchung 4711“, und antwortet dem Nutzer sofort. Ein oder mehrere Worker holen Aufträge aus der Warteschlange, erledigen sie und bestätigen den Abschluss. Erst nach dieser Bestätigung wird der Auftrag endgültig entfernt. Fällt ein Worker mitten in der Arbeit aus, wird der Auftrag nach einer Zeit erneut ausgeliefert. Für viele Anwendungen genügt eine einfache Lösung: Mit Bibliotheken wie BullMQ auf Redis oder Warteschlangen direkt in PostgreSQL braucht es kein zusätzliches, großes System.

3. Zustellung, Wiederholung, Fehler

Warteschlangen versprechen in der Regel eine Zustellung „mindestens einmal“. Das bedeutet: Ein Auftrag geht nicht verloren, kann aber in seltenen Fällen doppelt ausgeliefert werden, etwa wenn ein Worker ihn erledigt hat, aber vor der Bestätigung abstürzt. Deshalb müssen Worker idempotent sein – ein doppelt ausgeführter Auftrag darf keinen Schaden anrichten. Eine E-Mail sollte nicht zweimal verschickt, eine Gutschrift nicht zweimal gebucht werden. Das erreicht man mit Idempotenzschlüsseln oder Prüfungen wie „wurde für diese Buchung schon eine E-Mail versendet?“.

Schlägt ein Auftrag fehl, wird er mit wachsendem Abstand erneut versucht. Schlägt er dauerhaft fehl, etwa wegen fehlerhafter Daten, landet er nach einer festgelegten Zahl von Versuchen in einer Dead Letter Queue, einer Ablage für nicht verarbeitbare Aufträge. Dort können Menschen ihn untersuchen, ohne dass er die übrige Verarbeitung blockiert. Eine Dead Letter Queue, die niemand beobachtet, ist allerdings nutzlos; sie gehört in die Überwachung.

4. Rückstau und Backpressure

Eine Warteschlange puffert Spitzen, aber sie kann nicht zaubern. Wenn dauerhaft mehr Aufträge hineinkommen, als Worker abarbeiten können, wächst sie unbegrenzt. Probieren Sie es aus:

Die wichtigste Kennzahl einer Warteschlange ist deshalb ihre Länge beziehungsweise das Alter des ältesten Auftrags. Wächst sie dauerhaft, gibt es drei Möglichkeiten: mehr Worker starten, die Verarbeitung pro Auftrag beschleunigen oder den Zustrom begrenzen. Letzteres heißt Backpressure: Das System signalisiert dem Produzenten, dass es überlastet ist, etwa indem neue Aufträge vorübergehend abgelehnt oder verzögert werden. Das ist besser, als Aufträge anzunehmen, die erst in Stunden bearbeitet werden. Für automatische Skalierung ist die Länge der Warteschlange eine hervorragende Messgröße – viel aussagekräftiger als die Prozessorauslastung.

5. Nutzer informieren

Asynchrone Verarbeitung verändert die Nutzererfahrung. Statt eines Ergebnisses bekommt der Nutzer zunächst eine Bestätigung, dass der Auftrag angenommen wurde. Die Anwendung muss dann zeigen, wie es weitergeht. Bewährte Muster sind eine Statusanzeige, die regelmäßig abfragt oder per Push aktualisiert wird („Ihr Video wird verarbeitet – 60 %“), eine Benachrichtigung nach Abschluss und klare Hinweise bei Fehlern. Für das System bedeutet das: Jeder asynchrone Auftrag braucht einen gespeicherten Status in der Datenbank, der die Schritte „angenommen“, „in Arbeit“, „fertig“ und „fehlgeschlagen“ abbildet.

6. Wann eine Warteschlange zu viel ist

Nicht jede Anwendung braucht eine Warteschlange. Eine kleine Anwendung, die einmal am Tag eine E-Mail verschickt, kommt mit einem einfachen geplanten Job aus. Wer eine Warteschlange einführt, führt auch neue Fragen ein: Wie wird sie überwacht, wie werden fehlgeschlagene Aufträge behandelt, wie werden Worker ausgerollt, ohne laufende Aufträge zu verlieren? Die Faustregel: Eine Warteschlange lohnt sich, sobald Aufgaben länger als ein bis zwei Sekunden dauern, von unzuverlässigen externen Diensten abhängen, in großer Zahl anfallen oder die Antwort an den Nutzer nicht blockieren sollen. Für KI-Anwendungen trifft das fast immer zu, denn Anfragen an Sprachmodelle sind langsam, teuer und gelegentlich fehlerhaft. Die nächste Lektion zeigt eine verwandte, aber andere Technik: Event Streaming, bei dem Ereignisse nicht nur verarbeitet, sondern dauerhaft gespeichert und von vielen Stellen gelesen werden.

7. Geplante und wiederkehrende Aufgaben

Neben Aufträgen, die durch Nutzeraktionen entstehen, gibt es Aufgaben, die regelmäßig laufen: nächtliche Berichte, das Aufräumen abgelaufener Sitzungen, Erinnerungen an Termine am Vortag oder die Synchronisation mit einem externen System. Solche Aufgaben werden meist über einen Zeitplaner gestartet, der zu festgelegten Zeiten Aufträge in die Warteschlange legt. Bei mehreren Instanzen muss sichergestellt sein, dass eine Aufgabe nicht von jeder Instanz gleichzeitig gestartet wird; dafür eignen sich zentrale Planer oder Sperren in der Datenbank. Große Aufgaben werden in viele kleine Aufträge zerlegt, etwa ein Auftrag pro Kunde statt eines riesigen Auftrags für alle. So lassen sie sich parallel verarbeiten, und ein Fehler bei einem Kunden blockiert nicht die übrigen.

Auch für asynchrone Verarbeitung gilt: Was man nicht beobachtet, kann man nicht betreiben. Zu jeder Warteschlange gehören Kennzahlen wie die Zahl wartender Aufträge, das Alter des ältesten Auftrags, die Fehlerquote und die Bearbeitungsdauer, dazu Alarme, wenn diese Werte ungewöhnlich steigen. Ein Friseursalon, dessen Terminerinnerungen wegen eines hängenden Workers einen Tag lang nicht verschickt werden, bemerkt das sonst erst an leeren Stühlen und verärgerten Kunden.

Kurz gesagt: Alles, worauf der Nutzer nicht warten muss, gehört in den Hintergrund. Die Warteschlange macht das System schneller, robuster und besser skalierbar – vorausgesetzt, die Worker sind idempotent und die Warteschlange wird beobachtet. Beginnen Sie klein, mit einer einfachen Lösung auf Basis von Redis oder PostgreSQL, und wechseln Sie erst dann zu einem eigenen Nachrichtensystem, wenn die Anforderungen es wirklich verlangen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.