Message Queues: Warum entkoppelte Systeme stabiler skalieren

Die meisten Systemlandschaften in kleinen und mittleren Unternehmen sind direkt verdrahtet: Das Formular ruft das CRM auf, das CRM stößt die Rechnung an, die Rechnung geht an die Buchhaltungssoftware. Solange alle Beteiligten schnell und fehlerfrei antworten, funktioniert das. Aber genau diese Annahme bricht im entscheidenden Moment — bei der Rabattaktion, beim API-Ausfall des Anbieters, beim Update in der Nacht. Dann reißt die Kette an der schwächsten Stelle, und zwar komplett.

Was eine Message Queue macht — in einer Minute erklärt

Eine Message Queue ist ein Briefkasten zwischen zwei Systemen. Statt dass System A direkt bei System B anruft und auf Antwort wartet, wirft A eine Nachricht ein — „Bestellung 4711 eingegangen" — und arbeitet sofort weiter. System B holt die Nachricht ab, wenn es Kapazität hat, verarbeitet sie und bestätigt die Erledigung. Erst mit dieser Bestätigung verschwindet die Nachricht aus der Queue. Fällt B aus, bleibt die Nachricht liegen und wird später verarbeitet — sie geht nicht verloren.

Das Prinzip heißt asynchrone Verarbeitung: Annahme und Erledigung eines Auftrags werden zeitlich getrennt. Genau diese Trennung ist der Kern der Entkopplung.

Warum Entkopplung Stabilität bringt

• Lastspitzen werden zu Warteschlangen statt zu Ausfällen: Kommen in einer Minute 500 Bestellungen statt 50, füllt sich die Queue — und wird in den Minuten danach abgearbeitet. Ohne Queue lehnt das überlastete System Anfragen ab, und die Bestellung ist weg.
• Ausfälle bleiben lokal: Steht die Buchhaltungs-API zwei Stunden, sammeln sich die Belege in der Queue. Verkauf und Versand laufen ungestört weiter.
• Systeme skalieren unabhängig: Wird die Verarbeitung zu langsam, hängt man weitere Konsumenten an dieselbe Queue — ohne den Rest des Systems anzufassen.
• Nichts geht still verloren: Jede Nachricht ist entweder verarbeitet, in Arbeit oder wartet. Endgültig gescheiterte Fälle landen in einer Dead-Letter-Queue mit Fehlerkontext statt im Nirwana.

Ein Beispiel aus dem Tagesgeschäft

Ein Online-Händler verschickt nach jeder Bestellung eine Auftragsbestätigung, bucht den Lagerbestand ab und legt den Kunden im CRM an — bisher alles direkt im Bestellvorgang. Normal dauert das 2 Sekunden. Am Aktionstag mit zehnfacher Last antwortet das CRM plötzlich in 30 Sekunden, der Checkout läuft in Timeouts, und der Shop verliert genau dann Umsatz, wenn er am meisten verkaufen könnte.

Nach dem Umbau schreibt der Checkout nur noch eine Nachricht in die Queue und bestätigt dem Kunden sofort. Bestandsbuchung, CRM-Anlage und E-Mail laufen als getrennte Konsumenten dahinter. Am nächsten Aktionstag wächst die Queue kurz auf ein paar tausend Nachrichten — abgearbeitet in 20 Minuten, verlorene Bestellungen: null. Der Unterschied ist kein schnellerer Server, sondern eine andere Architektur.

Wann sich eine Queue lohnt — und wann nicht

Nicht jeder Prozess braucht eine Queue. Wo eine Antwort sofort gebraucht wird — etwa die Preisberechnung im Warenkorb — bleibt der direkte Aufruf richtig. Die Queue lohnt sich überall dort, wo das Ergebnis nicht in derselben Sekunde vorliegen muss: Rechnungen, E-Mails, Exporte, Synchronisationen, Auswertungen. Als Faustregel: Alles, was heute „im Hintergrund" laufen sollte, aber tatsächlich im Vordergrund blockiert, ist ein Kandidat. Technisch muss dafür niemand einen eigenen Kafka-Cluster betreiben — gehostete Dienste wie SQS, Cloud Tasks oder RabbitMQ-as-a-Service kosten für typische KMU-Volumina wenige Euro im Monat.

Was das für Entscheider bedeutet

Message Queues sind keine Frage der Unternehmensgröße, sondern der Abhängigkeit: Je mehr Umsatz an automatisierten Ketten hängt, desto teurer wird jede direkte Kopplung. Die Investition ist überschaubar — ein kritischer Prozess lässt sich in Tagen umstellen — und zahlt sich beim ersten Ausfall aus, den niemand bemerkt, weil die Queue ihn geschluckt hat. Die richtige Reihenfolge: erst den Prozess mit dem höchsten Schadenpotenzial entkoppeln, dann messen, dann den nächsten.