Kafka, Queue oder synchrones REST?
Kafka eignet sich für langlebige Event Streams, Replay und viele unabhängige Konsumenten. Für direkte Antworten oder einfache Arbeitsverteilung sind REST beziehungsweise Queue häufig klarer.
Zahlung ohne globale Transaktion
Eine Zahlung ist wie eine Überweisung mit mehreren beteiligten Stellen: Der Order Service fordert die Zahlung an, der Payment Service verarbeitet sie und meldet das Ergebnis zurück. Jeder Service führt nur seine eigene lokale Transaktion aus.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Order erstellt Zahlungsauftrag
- Event oder API-Aufruf erreicht Payment
- Payment prüft Idempotency Key
- Provider wird angesprochen
- Ergebnis wird gespeichert
- Payment Event aktualisiert Order.
Fachlicher Ablauf
Ein Kunde möchte eine Bestellung zuverlässig abschließen. Fachlich müssen Preis, Bestand, Zahlung und Bestellstatus zusammenpassen, auch wenn einzelne Schritte zeitversetzt erfolgen oder ein Teilsystem vorübergehend ausfällt.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Der Kunde sieht eine eindeutige Bestätigung oder einen nachvollziehbaren Zwischenstatus, niemals eine unklare Doppelbuchung.
Technischer Ablauf
Der Request erreicht das Gateway und den Order Service. Das Aggregate prüft Regeln, PostgreSQL speichert den lokalen Zustand, die Transactional Outbox hält das Event in derselben Transaction fest und Kafka verteilt es an Inventory, Payment und Notification. Correlation IDs verbinden Logs und Traces über alle Stationen.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Idempotency Key, Transaction Boundary, Outbox-Verarbeitung, Event-Status und End-to-End-Trace.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
Ausgangslage
Eine bestätigte Bestellung muss Inventory, Payment, Notification und Analytics zuverlässig erreichen.
Die Entscheidung wird nicht nach Mode, sondern nach Qualitätszielen, Teamfähigkeit, Betriebsmodell und Fault Tolerance getroffen.
Welche Frage wird wirklich entschieden?
Nicht „Welche Technologie ist moderner?“, sondern: Welche Option erfüllt die geschäftlichen Anforderungen mit der geringsten dauerhaft beherrschbaren Komplexität?
- Welche Benutzerwirkung muss geschützt werden?
- Welche Änderungen erfolgen wie häufig?
- Wer betreibt und verantwortet die Lösung?
- Welche Fehler müssen toleriert werden?
Option A: Kafka
Stärken: Gute Passung für den beschriebenen CommerceOne-Kontext, wenn Voraussetzungen und Betriebsfähigkeit vorhanden sind.
Nachteile: Zusätzliche Technik erzeugt Lern-, Betriebs-, Sicherheits- und Upgrade-Aufwand.
Option B: REST oder klassische Message Queue
Stärken: Häufig einfacher, schneller verständlich und mit weniger Betriebsfläche.
Nachteile: Kann bei Wachstum, mehreren Teams oder höheren Verfügbarkeitszielen Grenzen erreichen.
Bewertungskriterien
CommerceOne-Entscheidung
Empfehlung: Kafka – aber nur unter den dokumentierten Voraussetzungen. Die Alternative REST oder klassische Message Queue bleibt bevorzugt, wenn Organisation oder Lastbild einfacher sind.
Die Entscheidung wird als ADR festgehalten und nach sechs Monaten anhand realer Betriebsdaten überprüft.
Wann ausdrücklich nicht?
- Wenn das Team die Betriebsfolgen nicht verantworten kann.
- Wenn die Anforderungen auch mit einer wesentlich einfacheren Lösung erfüllt werden.
- Wenn die Entscheidung nur durch Trend, Anbieterfolie oder Lebenslaufoptimierung begründet wird.
Security, Performance und Betrieb
Security: Neue Komponenten erweitern Trust Boundaries (Trust Boundaries), Rechte und Patch-Flächen.
Performance: Latenz und Durchsatz müssen am End-to-End-Ablauf gemessen werden.
Betrieb: Für jede Option braucht CommerceOne Ownership, Telemetrie, Runbook, Backup- und Upgrade-Plan.
Kosten und organisatorische Folgen
Kosten bestehen nicht nur aus Infrastruktur. Entscheidend sind Bereitschaft, Schulung, Störungen, Security Reviews, Versionspflege und verlorene Entwicklungszeit. Die einfachere Option gewinnt, solange der zusätzliche Nutzen der komplexeren Option diese dauerhaften Kosten nicht übersteigt.
Entscheidungsfragen
- Welche Annahme könnte die Empfehlung kippen?
- Welche Kennzahl zeigt nach dem Einsatz, ob die Entscheidung erfolgreich war?
- Welche Exit-Strategie besteht, falls sich Kafka nicht bewährt?
Merksatz
Die beste Enterprise-Entscheidung ist nicht die technisch mächtigste, sondern die dauerhaft verständliche und betreibbare Lösung für das konkrete Problem.