Publisher
Ein System, das ein Ereignis veröffentlicht, etwa eine neue Bestellung, ein importierter Datensatz, ein Preisvorschlag oder ein Alert-Signal.
Wissens-Begriff
Pub/Sub
Pub/Sub steht für Publish-Subscribe-Messaging. In Google Cloud Pub/Sub senden Publisher Nachrichten an Topics, Subscriptions stellen diese Nachrichten bereit und Subscriber verarbeiten sie entkoppelt.
Definition
Pub/Sub entkoppelt Systeme, die sonst direkt voneinander abhängen.
Bei einem direkten API-Aufruf muss der Sender wissen, wer die Arbeit ausführt und ob das Zielsystem gerade erreichbar ist. Pub/Sub verschiebt diese Kopplung: Der Sender veröffentlicht ein Ereignis, die Verarbeitung passiert über eine oder mehrere Subscriptions.
Dadurch werden Backend-Prozesse, Datenpipelines, Alerts und AI-nahe Workflows stabiler planbar. Die Entkopplung löst aber nur technische Zustellung. Fachliche Prozesslogik, Event-Namen, Payload-Standards, Retry, Idempotenz und Dead Letter Topics müssen bewusst definiert werden.
Publisher, Topic, Subscription und Subscriber
Publisher
Shop, ERP, API, Backend, Scheduler oder Datenpipeline veröffentlicht ein Ereignis.
Topic
Das Ereignis landet auf einem benannten Kanal, ohne direkte Empfängerbindung.
Subscription
Eine oder mehrere Subscriptions steuern Zustellung, Acknowledgement und Retry.
Subscriber
Cloud Run, Cloud Functions, Dataflow oder Worker verarbeiten die Nachricht idempotent.
Begriffe
Die vier Grundbausteine von Publish Subscribe.
Topic
Ein benannter Kanal für Nachrichten. Publisher schreiben auf ein Topic, ohne den späteren Empfänger direkt kennen zu müssen.
Subscription
Eine Zustellungssicht auf ein Topic. Sie bestimmt, welche Subscriber Nachrichten erhalten und wie Zustellung, Retry und Acknowledgement laufen.
Subscriber
Ein empfangendes System, etwa Cloud Functions, Cloud Run, Dataflow oder ein Worker, der Nachrichten verarbeitet und Ergebnisse schreibt.
Abgrenzung
Direkter API-Aufruf, Queue, Pub/Sub und Kafka richtig unterscheiden.
Direkter API-Aufruf
Einfach und nachvollziehbar, aber stark gekoppelt. Sender wartet auf Empfänger, Fehler und Lastspitzen treffen beide Systeme direkt.
Message Queue
Eine Queue verteilt Arbeit an Konsumenten. Sie ist gut für Task-Verarbeitung, aber nicht automatisch ein breites Event-Verteilmodell.
Pub/Sub
Publish Subscribe entkoppelt Publisher und Subscriber über Topic und Subscription. Ein Ereignis kann mehrere unabhängige Verarbeitungen auslösen.
Kafka, SNS und SQS
Kafka ist stärker Streaming- und Portabilitäts-orientiert. AWS SNS und SQS erfüllen vergleichbare Messaging-Aufgaben im AWS-Ökosystem.
Einsatzfelder
Warum Messaging für Backend, Daten und Prozesse relevant wird.
01
Asynchrone API-Verarbeitung
API-Aufrufe können Arbeit an ein Topic übergeben, damit lange Jobs, Wiederholungen und Fehlerbehandlung nicht den ursprünglichen Request blockieren.
02
Datenimport und Datenvalidierung
Importe aus Shop, ERP, Marketingplattformen oder externen APIs können Ereignisse erzeugen, die Validierung, Speicherung und BigQuery-nahe Pipelines starten.
03
Event-Pipelines, Alerting und Signal-vs-Noise
Wichtige Änderungen, Datenlücken, Job-Ergebnisse und Fehler werden als Events modelliert, damit Benachrichtigungen nicht aus einzelnen Skripten verstreut entstehen.
04
Job-Orchestrierung und Entkopplung von Systemen
Cloud Run, Cloud Functions und Worker können über Nachrichten entkoppelt werden, wenn mehrere Prozessschritte unabhängig skalieren oder wiederholt werden müssen. Das hilft bei der Entkopplung von Shop, ERP, Backend, Data Warehouse und AI-Prozessen.
Grenzen
Typische Fehler bei eventgetriebener Architektur.
Retry-Logik planen
Wiederholungen lösen vorübergehende Fehler, können aber doppelte Verarbeitung auslösen. Jeder Subscriber braucht klare Acknowledgement- und Fehlerlogik.
Idempotenz sichern
Verarbeitende Systeme müssen mehrfach zugestellte Nachrichten erkennen oder folgenlos wiederholen können, etwa über Event-IDs und Statusspeicher.
Dead Letter Topics nutzen
Nicht verarbeitbare Nachrichten brauchen einen kontrollierten Zielort, damit Fehler sichtbar werden und keine Prozesskette stillsteht.
Payload-Standards festlegen
Ohne klare Event-Namen, Versionierung und Nutzlastregeln wird Pub/Sub zu Datenrauschen statt zu stabiler Business-Infrastruktur.
Verwandte Services
Wo Pub/Sub in Business-Infrastruktur praktisch wichtig wird.
API-Integrationen
Schnittstellen, Webhooks, Authentifizierung, Payloads, Fehlerfälle und asynchrone Verarbeitung sauber verbinden.
Service ansehen
Business-Infrastruktur-Automatisierung
Prozessketten über Shop, ERP, Backend, Data Warehouse, AI und interne Tools entkoppelt orchestrieren.
Service ansehen
Backend-Entwicklung
Cloud Run, Cloud Functions, Jobs, Worker und Statusspeicher als wartbare Backend-Architektur umsetzen.
Service ansehen
Preisautomatisierung
Preisvorschläge, Freigaben, Write-back, Readback-Verifikation und Alerts als kontrollierte Prozesskette modellieren.
Service ansehen
Marketing Data Warehouse
Events und Datenimporte in BigQuery-nahe Pipelines, Datenqualität und historisierte Auswertungen überführen.
Service ansehen
Verwandte Begriffe
Begriffe rund um Messaging, Pipelines und Cloud-Dienste.
Google Cloud PlatformCloud-Kontext für Pub/Sub, Cloud Run, Cloud Functions, BigQuery und Monitoring.Cloud FunctionsEventgetriebene Funktionen als möglicher Subscriber.Cloud RunServerlose Services und Worker für Pub/Sub-Verarbeitung.BigQueryAnalytisches Ziel für Datenpipelines und historisierte Events.ETL und ELTDatenflussmuster zwischen Quellen, Verarbeitung und Warehouse.
Entscheidung
Pub/Sub einsetzen, wenn Entkopplung wirklich hilft.
Ob ein direkter API-Aufruf reicht oder ob Messaging, Retry, Idempotenz, Dead Letter Topics und Monitoring eine stabilere Prozessarchitektur schaffen, hängt an Kopplungsgrad und Fehlertoleranz des Systems.
Ereignisse sollen Signale erzeugen, kein neues Datenrauschen.