Synchron oder
asynchron?

Bei synchroner Kommunikation sendet ein Aufrufer eine Anfrage und wartet im selben Interaktionszusammenhang auf die Antwort. Beide Seiten müssen während dieser Zeit erreichbar sein. Das passt zu kurzen Abfragen, unmittelbarer Validierung und Situationen, in denen die nächste Aktion das Resultat benötigt. Ein Browser fragt beispielsweise einen Preis ab und zeigt ihn direkt an.

Bei asynchroner Kommunikation wird Arbeit angenommen, gespeichert oder als Nachricht veröffentlicht. Der Absender muss nicht warten, bis die fachliche Verarbeitung abgeschlossen ist. Das Ergebnis kommt später über einen Status, eine Benachrichtigung oder ein weiteres Ereignis. Eine Queue puffert Last und überbrückt vorübergehende Ausfälle. Sie macht die Verarbeitung jedoch nicht automatisch korrekt.

Synchron und asynchron beschreiben nicht zwingend einen ganzen Geschäftsprozess. Ein Ablauf kann mehrere Modelle kombinieren. Microsoft Forms bestätigt beispielsweise die Übermittlung, während ein nachgelagerter Workflow später startet. Innerhalb dieses Workflows kann eine Logic App synchron eine API aufrufen. Die gesamte Reise vom Formular bis zum ERP ist deshalb nicht automatisch synchron, nur weil ein HTTP-Schritt synchron arbeitet.

Ein synchroner Aufruf ist leicht zu verstehen: Anfrage, Verarbeitung, Antwort. Er eignet sich für eine Produktverfügbarkeit, eine Berechtigungsprüfung oder das Laden von Studienmetadaten. Der Aufrufer kennt Erfolg oder Ablehnung unmittelbar und kann seine Benutzeroberfläche entsprechend steuern.

Die Kehrseite ist zeitliche Kopplung. Ruft eine Logic App ein Gateway, einen .NET-Service und Odoo nacheinander auf, addieren sich die Laufzeiten. Jeder Hop besitzt ein Timeout und kann ausfallen. Nach einem Timeout bei einem schreibenden Request ist sogar unklar, ob das Ziel die Aktion noch abgeschlossen hat. Ein blindes Wiederholen kann einen zweiten Auftrag erzeugen. Latenzbudgets, Idempotency-Keys und verständliche Fehlerantworten gehören deshalb zum synchronen Design.

Eine lange synchrone Kette verschiebt die schwächste Verfügbarkeit auf den gesamten Prozess. Fünf Systeme mit jeweils hoher Verfügbarkeit ergeben nicht automatisch eine ebenso hoch verfügbare Gesamtkette. Zudem blockieren wartende Verbindungen Ressourcen. Synchrone Verarbeitung sollte deshalb kurz, begrenzt und fachlich notwendig sein.

Eine Queue kann eine Nachricht haltbar speichern, bis ein Consumer sie verarbeitet. Der Sender und der Empfänger müssen nicht gleichzeitig verfügbar sein. Lastspitzen werden geglättet: Wenn in kurzer Zeit viele Shop-Bestellungen oder DICOM-Studien eintreffen, arbeitet der Consumer sie in seinem Tempo ab. Das verbessert Robustheit, erzeugt aber eventuelle Konsistenz. Der Zielzustand ist nicht sofort überall sichtbar.

Der Vertrag muss nun zusätzliche Fragen beantworten: Was bedeutet „angenommen“? Wie fragt der Benutzer den Status ab? Wie lange darf die Verarbeitung dauern? Was geschieht bei einem fachlichen Fehler? Darf die Reihenfolge variieren? Können Nachrichten mehrfach eintreffen? Eine Queue löst diese Fragen nicht, sie macht sie sichtbar.

Ein Event beschreibt eine bereits eingetretene Tatsache, etwa ImagingStudyAvailable. Ein Command fordert eine konkrete Aktion, etwa AnonymizeStudy. Ereignisse sind in der Vergangenheit formuliert und können mehrere interessierte Konsumenten haben. Commands besitzen typischerweise einen verantwortlichen Empfänger. Diese Unterscheidung erleichtert Verantwortlichkeit und Benennung.

Die Metapher: Synchron ist wie ein Telefongespräch: Beide Personen müssen gleichzeitig verfügbar sein, und die anrufende Person wartet auf die Antwort. Asynchron ist wie eine Rohrpostsendung im Spital: Eine beschriftete, quittierte Sendung wird in ein Transportsystem gegeben, zwischengelagert und später von der zuständigen Stelle verarbeitet.

Die Grenze: Eine technische Queue kann Nachrichten duplizieren, nach Priorität oder Partition verteilen und über lange Zeit speichern. Eine Rohrpost garantiert weder automatisch die fachliche Richtigkeit des Inhalts noch bildet sie parallele Consumer exakt ab. Auch bedeutet „angenommen“ bei Software nicht „erfolgreich verarbeitet“.

1. Nutze synchron, wenn die nächste Benutzer- oder Systemaktion das Ergebnis sofort benötigt.
2. Nutze asynchron bei langer Verarbeitung, Lastspitzen oder wenn Zielsysteme zeitweise ausfallen dürfen.
3. Definiere bei asynchroner Annahme Status, Frist, Benachrichtigung und Fehlerweg.
4. Halte synchrone Ketten kurz und lege pro Hop ein begründetes Timeout fest.
5. Plane bei schreibenden Wiederholungen eine fachliche Idempotenzstrategie.
6. Unterscheide den gesamten Geschäftsprozess von einzelnen synchronen oder asynchronen Hops.
7. Beurteile Datenkritikalität und Dringlichkeit: Ein Forschungsworkflow ist kein klinischer Notfallpfad.