Wer eine Unified Namespace (UNS)-Architektur entwirft, trifft an jeder Schnittstelle eine Grundsatzentscheidung. Soll ein System auf eine Antwort warten, bevor es weiterarbeitet? Oder soll es Daten senden und sich nicht darum kümmern, wer sie wann verarbeitet? Diese Entscheidung zwischen synchroner und asynchroner Kommunikation bestimmt maßgeblich, wie robust, skalierbar und wartbar eine Architektur am Ende ist. Eine pauschale Antwort auf die Frage synchrone vs asynchrone Kommunikation gibt es nicht. Sie hängt vom konkreten Use Case ab: einer produktionskritischen Steuerung oder der Verteilung von Daten an viele Consumer. Dieser Artikel erklärt die Grundlagen der beiden Muster und liefert konkrete Entscheidungskriterien für typische Industrial-IoT-Szenarien. Er zeigt außerdem, wie Teams synchrone und asynchrone Kommunikation in Protokollen HTTP, MQTT und NATS praktisch umsetzen und welche Vor-und Nachteile damit einhergehen.
Synchrone vs. asynchrone Kommunikation: Die Grundlagen
Die Frage Synchrone vs asynchrone Kommunikation hat im UNS-Kontext zwei Dimensionen. Sie fließen in der Praxis oft ineinander: das Zeitverhalten der Kommunikation und das Verteilungsmuster. Eine klare Trennung beider Dimensionen ist die Voraussetzung für eine fundierte Antwort.
Synchrone Kommunikation bedeutet: Der Sender blockiert nach dem Senden einer Anfrage und wartet aktiv auf eine Antwort, bevor er weiterarbeitet. Der Ablauf ist linear und deterministisch – aber auch abhängig davon, dass der Empfänger rechtzeitig antwortet.
Asynchrone Kommunikation bedeutet: Der Sender publiziert eine Nachricht und fährt sofort fort, ohne auf eine Antwort zu warten. Verarbeitung und Reaktion sind zeitlich entkoppelt – der Sender weiß nicht, wann oder ob jemand die Nachricht verarbeitet.
Orthogonal dazu steht die zweite Dimension: Request/Reply (auch Request/Response genannt) versus Pub/Sub. Request/Reply ist ein Punkt-zu-Punkt-Muster mit einer erwarteten Antwort auf eine konkrete Anfrage. Pub/Sub ist ein entkoppeltes Verteilungsmuster, bei dem ein Sender auf ein Topic bzw. Subject publiziert, ohne die Empfänger zu kennen.
In der Praxis setzen viele Architekten synchrone Kommunikation mit Request/Reply gleich und asynchrone Kommunikation mit Pub/Sub. Das stimmt im Kern, aber nicht vollständig: Es gibt auch asynchrones Request/Reply. Der Sender stellt die Anfrage nicht blockierend, erwartet aber trotzdem eine konkrete, korrelierte Antwort. Wie das in MQTT und NATS konkret aussieht und welche Vor-und Nachteile das mit sich bringt, zeigt der Praxisteil weiter unten.
Vor- und Nachteile im Überblick
Die folgende Tabelle stellt die zentralen Eigenschaften von synchronem Request/Reply und asynchronem Pub/Sub gegenüber. Sie liefert die Faktenbasis für die Entscheidung synchrone vs asynchrone Kommunikation in der eigenen Architektur:
| Kriterium | Synchron / Request-Reply | Asynchron / Pub-Sub |
|---|---|---|
| Kopplung | eng – Sender kennt Empfänger, muss dessen Verfügbarkeit voraussetzen | lose – Sender kennt Empfänger nicht, Verfügbarkeit ist irrelevant |
| Latenz-Verhalten | Sender blockiert bis zur Antwort | Sender blockiert nicht, Verarbeitung erfolgt zeitversetzt |
| Skalierbarkeit (1:n) | eingeschränkt – für 1:n-Verteilung ungeeignet | sehr gut – ein Sender, beliebig viele Consumer |
| Fehlertoleranz | gering – Ausfall des Empfängers blockiert oder scheitert den Aufruf direkt | hoch – Consumer-Ausfall hat keine direkte Rückwirkung auf den Sender |
| Nachvollziehbarkeit der Antwort | hoch – Erfolg/Fehler ist unmittelbar bekannt | gering – kein eingebautes Feedback, ob und wie verarbeitet wurde |
| Implementierungsaufwand | niedrig für einfache Anfragen | niedrig für Verteilung, höher für Korrelation/Antwortlogik (abhängig vom Protokoll, siehe unten) |
Weder eine enge noch eine lose Kopplung ist grundsätzlich besser. Beide Kommunikationsmuster erfüllen unterschiedliche Anforderungen und sollten gezielt entsprechend des jeweiligen Anwendungsfalls eingesetzt werden. Eine synchrone Kommunikation mit enger Kopplung eignet sich überall dort, wo eine unmittelbare und verlässliche Rückmeldung erforderlich ist. Beispielsweise bei Steuerbefehlen, deren erfolgreiche Ausführung direkt bestätigt werden muss.
Problematisch wird eine enge Kopplung hingegen, wenn sie in Bereichen eingesetzt wird, die auf Entkopplung, Skalierbarkeit und Erweiterbarkeit ausgelegt sein sollten. Ein typisches Beispiel ist die Verteilung von Telemetriedaten: Müssen Messwerte gleichzeitig an Dashboards, Datenbanken, Analyseplattformen oder weitere Verbraucher verteilt werden, bietet ein asynchrones Publish/Subscribe-Modell deutliche Vorteile. Neue Consumer können jederzeit hinzugefügt werden, ohne den Sender anzupassen oder dessen Verfügbarkeit zu beeinflussen.
Entscheidungskriterien: Welches Muster für welchen Use Case?
Die Entscheidung synchrone vs asynchrone Kommunikation sollte sich also an den Anforderungen des jeweiligen Use Cases orientieren. Die folgende Matrix ordnet typische UNS-Szenarien den beiden Dimensionen zu:
| Request/Reply | Pub/Sub | |
|---|---|---|
| Synchron | Produktionskritische Steuerung (Echtzeit): Freigabe eines Sicherheitskreises, bei der die Ausführung sofort bestätigt werden muss. Deterministisches Verhalten zählt hier mehr als Entkopplung. | Kein sinnvoller Use Case. Ein Publisher, der blockiert, bis alle Subscriber quittiert haben, widerspricht dem Zweck von Pub/Sub – loser Kopplung und beliebig vielen Consumern. Diese Kombination kommt im UNS praktisch nicht vor. |
| Asynchron | Produktionssteuernde Prozesse / IT-Integration: Sollwertänderungen oder MES-/ERP-Abfragen mit Timeout und Retry-Logik – korrelierte Antwort, aber ohne blockierende Verbindung. | Verteilung von Daten an viele Consumer: Telemetriedaten für Dashboards, Historian, MES und Analytics. Neue Consumer lassen sich hinzufügen, ohne den Sender zu beeinflussen. |
Als Faustregel gilt: Je mehr potenzielle Consumer dieselbe Information benötigen, desto klarer spricht die Antwort auf asynchrone Kommunikation über Pub/Sub. Je unmittelbarer ein Consumer eine einzelne, korrelierte Antwort braucht, desto eher ist Request/Reply die richtige Wahl.
Praxis: Umsetzung in populären Protokollen
HTTP, MQTT und NATS setzen synchrone und asynchrone Kommunikationsmuster sehr unterschiedlich um.
HTTP/REST
HTTP ist von Natur aus synchrones Request/Reply: Ein Client sendet eine Anfrage und wartet auf die Antwort, bevor er fortfährt. Das bringt reale Vorteile wie Einfachheit, universelles Tooling, und Kompatibilität mit praktisch jeder Firewall- und Proxy-Infrastruktur. Diese Eigenschaften haben HTTP zum Rückgrat des Internets gemacht.
Im UNS-Kontext liegt der Nachteil von HTTP im Architekturprinzip: der fehlende Single Source of Truth (SSOT). Fragt jeder Consumer denselben Wert per HTTP direkt beim Quellsystem ab, entstehen n einzelne Punkt-zu-Punkt-Abfragen statt eines zentralen, verteilten Datenpunkts. Das Quellsystem trägt die Last aller Abfragen selbst (HTTP kennt keine Push-Semantik). Jeder neue Consumer erzeugt so zusätzliche direkte Last auf dem Ursprungssystem. Im UNS liegen die Daten dagegen zentral vor. Ein Pub/Sub-Mechanismus verteilt sie an beliebig viele Consumer, unabhängig davon, wie viele es sind.
MQTT
MQTT ist primär auf Pub/Sub ausgelegt: Ein Publisher sendet auf ein Topic, beliebig viele Subscriber empfangen die Nachricht über den Broker. Publisher und Subscriber kennen sich dabei nicht. Das ist die Grundlage für asynchrone Datenverteilung im UNS – lose gekoppelt, gut skalierbar, mit QoS-Stufen für kontrollierte Zustellgarantien. Bei der Frage synchrone vs asynchrone Kommunikation deckt MQTT damit grundsätzlich beide Seiten ab. Der Standardfall ist asynchrones Pub/Sub, ergänzt um ein nachgebautes Request/Reply-Muster für punktuelle, korrelierte Antworten.
Request/Reply über MQTT (asynchron nachgebaut): MQTT bietet seit Version 5.0 die Properties response-topic und correlation-data. Damit bilden Entwickler ein Request/Reply-Muster auf Pub/Sub-Basis nach. Ein Client publiziert beispielsweise auf machine/42/cmd/setSpeed mit response-topic: machine/42/cmd/setSpeed/reply und correlation-data: <uuid>. Der Empfänger verarbeitet die Anfrage und publiziert seine Antwort auf das übermittelte Response-Topic – mit derselben Correlation-Data. So ordnet der ursprüngliche Client die passende Antwort zu.
Der Nachteil dieser Umsetzung: Es gibt kein natives Timeout- oder Fehlerhandling. Entwickler müssen es applikationsseitig selbst bauen. Konkret bedeutet das: Der anfragende Client startet selbst einen Timer, sobald er die Anfrage publiziert. Trifft nach Ablauf der Frist keine Antwort mit passender Correlation-Data ein, muss die Anwendung selbst einen Timeout-Fehler auslösen und behandeln. Der Broker kennt „offene Anfragen“ nicht und meldet auch nichts. Für Monitoring und Alarming heißt das konkret: Es gibt keine Broker-native Sicht auf ausstehende oder fehlgeschlagene Anfragen. Wer erkennen will, dass eine Anfrage nie eine Antwort erhalten hat, muss selbst eine Timeout-Tabelle mit offenen Correlation-IDs führen. Läuft der Timeout ab, publiziert die Anwendung entweder eine eigene Alarm-Nachricht auf ein separates Alarm-Topic oder erzeugt eine Metrik bzw. ein Application-Log. Auf UNS- bzw. Broker-Ebene existiert dafür keine eingebaute Sichtbarkeit.
NATS
NATS unterstützt Pub/Sub genauso wie MQTT, geht beim Request/Reply-Muster aber einen entscheidenden Schritt weiter. Request/Reply ist hier nativer Bestandteil des Protokolls, nicht über Konventionen nachgebaut. Für die Frage Synchrone vs asynchrone Kommunikation bedeutet das: Beide Muster laufen über dieselbe Infrastruktur, ohne dass eines der beiden als Workaround wirkt. Ein Client ruft schlicht nc.Request(subject, data, timeout) auf. NATS generiert dafür automatisch ein einmaliges Inbox-Subject (_INBOX.<random>) für die Antwort; der Timeout ist ein eingebauter Parameter des Aufrufs:
msg, err := nc.Request("machine.42.cmd.setSpeed", payload, 2*time.Second)
Der Vorteil gegenüber MQTT liegt in genau den Punkten, die Entwickler bei MQTT selbst bauen müssen. NATS braucht keine manuelle Correlation-ID-Verwaltung, keinen Konventions-Overhead für Response-Topics und bringt ein eingebautes Timeout- und Fehlerhandling mit. Lauscht niemand auf das angefragte Subject, liefert NATS ein explizites Fehlersignal zurück: no responders available. Dieses Signal gibt es in MQTT nicht. Dort verläuft eine Anfrage ohne Antwort schlicht im Timeout. Der Client kann dabei nicht unterscheiden, ob niemand zuständig war oder die Antwort nur verspätet eintrifft. Pub/Sub und Request/Reply laufen zudem über dieselbe Infrastruktur, ohne Protokollbruch.
Gegenüberstellung: Request/Reply in HTTP, MQTT und NATS
| Kriterium | HTTP | MQTT (nachgebaut) | NATS (nativ) |
|---|---|---|---|
| Timeout-Handling | eingebaut (Client-Timeout) | applikationsseitig zu bauen | eingebauter Parameter |
| Korrelation | implizit (eine TCP-Verbindung) | manuell via correlation-data |
automatisch via Inbox-Subject |
| Fehlersignal bei fehlendem Empfänger | HTTP-Statuscode (z. B. 404/503) | keins – stiller Timeout | explizit (no responders) |
| Infrastruktur-Overhead | gering, aber getrennt vom UNS-Backbone | gering, gleiche Infrastruktur wie Pub/Sub | gering, gleiche Infrastruktur wie Pub/Sub |
| Implementierungsaufwand | gering – nativ unterstützt | hoch – Korrelation, Timeouts und Fehlerbehandlung selbst implementieren | gering – Request/Reply ist Bestandteil des Protokolls |
| Empfehlung für UNS | ✅ ja | ❌ nein | ✅ ja |
Best Practices für die Wahl des Kommunikationsmusters im UNS
Die folgenden Empfehlungen helfen, die Entscheidung im UNS konsistent zu treffen, statt sie von Fall zu Fall zu entscheiden.
Do
- Pub/Sub als Standard: Im UNS-Backbone sollte Pub/Sub die Grundeinstellung sein. Systeme publizieren Daten zentral, alle Consumer greifen darauf zu, ohne Kopplung an einzelne Abnehmer.
- Request/Reply gezielt einsetzen: für IT-Abfragen, Steuerbefehle und Bestätigungen mit konkreter, korrelierter Antwort – synchron über HTTP für Systemgrenzen, asynchron über MQTT/NATS im UNS.
- Timeouts explizit definieren: Jede Request/Reply-Implementierung braucht eine bewusst gewählte Timeout-Strategie, unabhängig vom Protokoll.
Avoid
- Synchrone Kopplung für Echtzeit-Telemetrie: Kontinuierliche Messwerte oder Statusdaten gehören nie in blockierende Request/Reply-Aufrufe. Das erhöht die Fehleranfälligkeit und bindet Sender und Empfänger unnötig aneinander.
- MQTT-Request/Reply ohne Timeout-Logik: Wer Correlation-Data nutzt, aber keine eigene Timeout- und Alarm-Logik implementiert, riskiert unbemerkt hängende Anfragen ohne jede Sichtbarkeit.
In der Praxis bewährt sich ein Hybridmuster: MQTT oder NATS Pub/Sub übernehmen die kontinuierliche Datenverteilung an alle Consumer. Gezielte Request/Reply-Bridges ergänzen das dort, wo IT-Systeme oder Steuerungslogik eine konkrete, korrelierte Antwort brauchen.
Fazit
Die Frage Synchrone vs asynchrone Kommunikation hat keine universelle Antwort. Sie hängt davon ab, wie viele Consumer eine Information benötigen und wie unmittelbar ein Use Case eine korrelierte Antwort braucht. Für die Verteilung von Daten an viele Consumer ist asynchrones Pub/Sub die richtige Wahl. Für produktionskritische Steuerbefehle und IT-Abfragen passt dagegen Request/Reply – synchron oder asynchron nachgebildet. Entscheidend ist, das Muster bewusst dem Use Case zuzuordnen, statt ein einzelnes Muster über die gesamte Architektur zu erzwingen. Dann wird aus Synchrone vs asynchrone Kommunikation keine Grundsatzfrage, sondern eine wiederholbare Architekturentscheidung.
Drei zentrale Erkenntnisse
- Zwei orthogonale Dimensionen: Synchron/asynchron beschreibt das Zeitverhalten, Request-Reply/Pub-Sub das Verteilungsmuster – Architekten sollten beide Dimensionen getrennt betrachten.
- Pub/Sub ist der UNS-Standard: Für Datenverteilung an viele Consumer ist asynchrones Pub/Sub die richtige Grundlage – dank geringer Kopplung und guter Skalierbarkeit.
- NATS reduziert den Implementierungsaufwand für Request/Reply: Wo MQTT applikationsseitige Timeout- und Korrelationslogik erfordert, bietet NATS dieselbe Funktionalität nativ und protokollintegriert.
