Wie wird die 'Fan-out' Problematik in Event-Driven Architectures technisch durch Message-Bus-Pattern gelöst?

Die Fan-out-Problematik tritt auf, wenn ein einzelnes Ereignis in einer verteilten Systemlandschaft von mehreren unabhängigen Services gleichzeitig verarbeitet werden muss. Ohne ein entsprechendes Pattern müsste der Producer jede Nachricht einzeln an jeden Consumer senden, was zu einer starken Kopplung führt und die Wartbarkeit bei steigender Anzahl an Services reduziert.

Wir lösen dieses Problem technisch durch die Implementierung des Publish-Subscribe-Patterns innerhalb eines Message-Bus. Anstatt direkte Verbindungen zu den Empfängern aufzubauen, sendet der Producer die Nachricht an einen zentralen Austauschpunkt, den sogenannten Exchange (in RabbitMQ) oder ein Topic (in Apache Kafka). Der Message-Broker übernimmt die Verantwortung für die Distribution.

Der technische Ablauf gestaltet sich wie folgt:

  1. Publishing: Der Producer sendet ein Event an ein spezifisches Topic.
  2. Routing: Der Broker prüft, welche Queues an dieses Topic gebunden (bound) sind.
  3. Replikation: Der Broker kopiert die Nachricht in jede einzelne dieser Queues.
  4. Consumption: Jeder Consumer liest die Nachricht aus seiner eigenen, dedizierten Queue und verarbeitet sie asynchron.

Die folgende Tabelle verdeutlicht den Unterschied zwischen einer Point-to-Point-Kommunikation und dem Fan-out-Ansatz:

MerkmalPoint-to-PointFan-out (Pub/Sub)
EmpfängerGenau ein ConsumerBeliebig viele Consumer
KopplungStark (Sender kennt Ziel)Lose (Sender kennt nur Topic)
SkalierbarkeitGering (manuelle Anpassung nötig)Hoch (dynamisches Hinzufügen von Services)
FehlertoleranzFehler beim Empfänger blockieren SenderIsolierte Fehler in einzelnen Queues

Durch diese Architektur entkoppeln wir die Geschäftslogik des Producers von der Anzahl und Art der Consumer. Dies ist besonders bei komplexen Systemen relevant, bei denen wir im Rahmen unserer IT-Consulting & Digitale Strategie darauf achten, dass neue Microservices ohne Änderung am bestehenden Code integriert werden können. Die Lastverteilung erfolgt dabei effizient über den Broker, der die Nachrichtenpersistenz und die Zustellung garantiert.

Wir empfehlen für produktive Umgebungen den Einsatz von Log-basierten Brokern wie Apache Kafka, da diese durch das Offset-Management eine deutlich höhere Performance und die Möglichkeit zum Replay von Events bieten als klassische Message-Queues.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt