Publisher-Subscriber-Entwurfsmuster

Publisher-Subscriber-Entwurfsmuster

Das Publisher-Subscriber-Entwurfsmuster (kurz: Pub/Sub) ist ein **Verhaltens- und Integrationsmuster**, das die **asynchrone, lose gekoppelte Kommunikation** zwischen Softwarekomponenten ermöglicht. Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine **vermittelnde Instanz** (z. B. Message Broker oder Event-Bus) verteilt.

Ziel

Das Muster soll:

• **Abhängigkeiten zwischen Sender und Empfänger vermeiden**
• **Asynchrone Kommunikationsabläufe ermöglichen**
• **Skalierbarkeit verbessern**
• **Flexibilität und Erweiterbarkeit des Systems erhöhen**
• **Ereignisgesteuerte Architekturen unterstützen**

Grundprinzip

Komponenten, die Nachrichten senden möchten, veröffentlichen diese bei einem **Publisher** oder über einen **Message Broker**. Komponenten, die Nachrichten empfangen möchten, registrieren sich (abonnieren) bei einem **Subscriber**-Interface oder beim Broker. Der Publisher kennt die Subscriber **nicht** direkt.

Grafische Darstellung

       Publisher                  Subscriber
       (Sendet Events)           (Empfängt Events)
            |                           ^
            |                           |
            v                           |
       +--------- Message Broker --------+

Komponenten

Komponente	Rolle
**Publisher**	Erzeugt und veröffentlicht Nachrichten/Ereignisse.
**Subscriber**	Registriert sich für bestimmte Nachrichten und verarbeitet sie.
**Broker / Event Bus**	Vermittelt Nachrichten zwischen Publishern und Subscribern.

Ablauf

1. Der **Subscriber** meldet sich beim Broker für bestimmte Themen oder Ereignisse an. 2. Der **Publisher** sendet eine Nachricht an den Broker. 3. Der Broker verteilt die Nachricht automatisch an alle relevanten Subscriber. 4. Die Subscriber verarbeiten die Nachricht unabhängig voneinander.

Themenbasierte vs. ereignisbasierte Varianten

Themenbasiert (Topic-based)

Subscriber abonnieren Nachrichten zu bestimmten **Themen (Topics)**. Beispiel:

topic = "sensor/temperatur"

Alle Subscriber dieses Topics erhalten die Nachrichten.

Ereignisbasiert (Event-based)

Nachrichten definieren **spezifische Ereignisse**, z. B.:

Event: "Benutzer wurde erstellt"

Nur Subscriber dieses Ereignisses werden informiert.

Beispiel in Python (vereinfachter Event-Bus)

class EventBus:
    def __init__(self):
        self.subscribers = {}

    def subscribe(self, event, callback):
        self.subscribers.setdefault(event, []).append(callback)

    def publish(self, event, data):
        for callback in self.subscribers.get(event, []):
            callback(data)

bus = EventBus()

def handler(msg):
    print("Empfangen:", msg)

bus.subscribe("test_event", handler)
bus.publish("test_event", "Hallo Pub/Sub")

Beispiele in realen Systemen

| System | Rolle | |-------|-------| | **RabbitMQ** | Topic/Fanout Exchanges für Pub/Sub | | **Apache Kafka** | Verteilt Nachrichtenströme an Consumer-Gruppen | | **Redis Pub/Sub** | Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen | | **WebSockets / Socket.IO** | Ereignisbasierte Kommunikation in Echtzeit-Anwendungen | | **Cloud Pub/Sub (Google/AWS/Azure)** | Globale Messaging-Systeme für verteilte Microservices |

Vorteile

• **Lose Kopplung** zwischen Komponenten
• **Hohe Skalierbarkeit** durch parallele Verarbeitung
• **Unterstützt verteilte und eventgesteuerte Architekturen**
• **Wiederverwendbarkeit und Erweiterbarkeit** der Systemkomponenten

Nachteile

• **Nachrichtenfluss nicht direkt nachvollziehbar** (Debugging komplexer)
• **Keine garantierte Reihenfolge**, wenn nicht explizit unterstützt
• **Fehlerhandling und Retry-Strategien** müssen bewusst implementiert werden
• Potenzielle **Zustandsinkonsistenzen**, wenn Ereignisse zeitlich variieren

Best Practices

• Nachrichten **idempotent** verarbeiten (Doppelausführung darf keine Fehler verursachen)
• **Monitoring von Queues und Topics**
• Verwendung eines **zentralen Event-Schemas** bei verteilten Teams
• Klare **Namenskonventionen** für Topics/Ereignisse

Vergleich zu anderen Mustern

Muster	Vergleichspunkt	Unterschied
Pub/Sub	Kommunikation	Asynchron und entkoppelt
Observer	Kommunikation	Direkte Objektbeziehung ohne Broker
Competing Consumer	Verarbeitung	Mehrere Consumer teilen sich eine Queue (Lastverteilung), aber ohne Broadcast an mehrere Empfänger

Zusammenfassung

Das Publisher-Subscriber-Entwurfsmuster ermöglicht **asynchrone, lose gekoppelte Kommunikation** zwischen Softwarekomponenten. Publisher senden Ereignisse ohne Wissen über Empfänger, während Subscriber flexibel Ereignisse abonnieren. Es bildet das Fundament vieler **eventgesteuerter, verteilter und skalierbarer Softwaresysteme**.

Siehe auch

• Competing-Consumer-Entwurfsmuster
• Mediator-Entwurfsmuster
• Event-Driven Architecture
• RabbitMQ
• Apache Kafka

Weblinks

• https://www.enterpriseintegrationpatterns.com/
• https://refactoring.guru/design-patterns/publisher-subscriber
• https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern