Messaging Architecture: Sync/Async, MOM & ESB

In verteilten Systemen (z.B. Microservices) ist die Kommunikation zwischen den einzelnen Komponenten oft die grösste Herausforderung. Wie stellen wir sicher, dass Systeme zuverlässig miteinander sprechen, ohne sich gegenseitig zu blockieren?

Hier kommen verschiedene Kommunikationsmuster (Synchron vs. Asynchron) und Middleware-Lösungen (MOM und ESB) ins Spiel. (Ich habe mich entschieden, alles in einem umfassenden Post zu bündeln, da die Konzepte fliessend ineinander übergehen!)

1. ☎️ Synchrones vs. Asynchrones Messaging

Bevor man Systeme vernetzt, muss man sich für die Art der Kommunikation entscheiden. Beide Ansätze haben ihre Daseinsberechtigung.

Synchron (Das “Telefonat”)

Bei der synchronen Kommunikation sendet System A eine Anfrage an System B und wartet (blockiert), bis System B eine Antwort liefert (z.B. klassische REST HTTP-Calls).

  • Vorteil: Sehr einfach zu implementieren. Der Ablauf ist leicht nachzuvollziehen (Request/Response).
  • Nachteil: Strikte Kopplung. Wenn System B ausfällt oder langsam ist, steht auch System A still (Dominoeffekt).

Asynchron (Der “Briefverkehr”)

System A sendet eine Nachricht ab und arbeitet sofort weiter (“Fire and Forget”). Es wartet nicht auf System B.

  • Vorteil: Extreme Skalierbarkeit und lose Kopplung. Wenn System B ausfällt, geht die Nachricht nicht verloren, sondern wird verarbeitet, sobald B wieder da ist.
  • Nachteil: Fehlerbehandlung ist komplexer. Man weiss nicht sofort, ob die Verarbeitung erfolgreich war.

2. 📮 MOM (Message-Oriented Middleware)

Um asynchrones Messaging in der Praxis sauber umzusetzen, nutzt man ein MOM. Ein MOM ist sozusagen das Postamt in deiner Architektur. Bekannte Beispiele: ActiveMQ, RabbitMQ, Kafka.

Das MOM nimmt Nachrichten entgegen und stellt sicher, dass sie beim richtigen Empfänger ankommen. Dabei gibt es zwei Hauptkonzepte:

A) Message Queues (Point-to-Point)

  • Der Sender legt eine Nachricht in eine “Warteschlange” (Queue).
  • Ein einziger Empfänger (Consumer) holt sich die Nachricht ab und verarbeitet sie.
  • Beispiel: Ein E-Mail-Service, der Registrierungsmails nacheinander abarbeitet.

B) Topics (Publish / Subscribe)

  • Der Sender (Publisher) veröffentlicht eine Nachricht zu einem bestimmten Thema (Topic).
  • Mehrere Empfänger (Subscriber), die dieses Topic abonniert haben, erhalten eine Kopie der Nachricht.
  • Durable vs. Non-Durable Subscribers: Standardmässig erhalten Subscriber nur Nachrichten, während sie online sind (Non-Durable). Fällt ein Subscriber aus, verpasst er die Nachrichten. Um das zu verhindern, kann er sich als Durable Subscriber registrieren: Der Broker merkt sich dann, welche Nachrichten der Subscriber während seiner Offline-Zeit verpasst hat, und liefert sie nach, sobald er wieder online kommt.
  • Beispiel: Ein Benutzer ändert seine Adresse. Sowohl der Rechnungs-Service als auch der Versand-Service werden darüber informiert.

Der grosse Vorteil von MOM: Sender und Empfänger müssen sich nicht kennen. Sie müssen nicht einmal zur exakt selben Zeit online sein!

3. 🔀 ESB (Enterprise Service Bus)

Wenn die Systemarchitektur wächst und dutzende Legacy-Systeme, Cloud-Services und Datenbanken miteinander sprechen müssen, reicht reines “Nachrichten verschicken” (MOM) oft nicht mehr aus. Ein ESB baut quasi auf dem MOM auf und bietet zusätzliche “Intelligenz”.

Während ein MOM einfach nur ein Nachrichten-Kurier ist, ist ein ESB wie ein intelligenter Logistik-Hub. Bekannte Beispiele: Apache Camel, MuleSoft, IBM App Connect.

Die Kernaufgaben eines ESB:

  1. Routing: Wohin muss diese Nachricht basierend auf ihrem Inhalt? (Inhaltsbasiertes Routing).
  2. Transformation: System A spricht JSON, System B versteht aber nur XML? Der ESB übersetzt das Datenformat on-the-fly.
  3. Protokoll-Konvertierung: System A schickt Daten über HTTP, das Zielsystem B empfängt aber Daten über FTP oder eine SOAP-Schnittstelle. Der ESB schlägt die Brücke.
  4. Orchestrierung: Der ESB kann einen Prozess steuern (z.B. “Frage erst System X, berechne etwas, und speichere das Resultat in System Y”).

MOM vs ESB Visualisierung MOM vs ESB Visualisierung

(Hinweis: Für diesen Platzhalter kannst du später ein echtes Bild von dir einfügen!)

4. 🎯 Fazit

  • Nutze direkte synchrone APIs (REST/gRPC), wenn du in Echtzeit eine Antwort brauchst (z.B. UI-Interaktionen).
  • Nutze eine MOM (ActiveMQ/RabbitMQ), wenn du Microservices entkoppeln und skalieren möchtest (Warteschlangen für Jobs).
  • Nutze einen ESB, wenn du komplexe Unternehmenssysteme (Legacy vs. Cloud) integrieren musst, die unterschiedliche Protokolle und Formate sprechen. In modernen Microservice-Architekturen verzichtet man heute allerdings oft auf fette ESBs zugunsten von “Smart Endpoints and Dumb Pipes” (MOM).

📚 Weiterführende Links & Quellen