Payment verarbeitet OrderPaymentRequested mit stabiler Event-ID und Order-ID. Ein bereits verarbeiteter Eingang wird erkannt.
CommerceOne Architekturgeschichte
Zahlung ohne verteilte Transaktion
Payment-Autorisierung, fachliche Zustände, Saga und Kompensation.
0 % geöffnet
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.
1. Payment erhält eine Zahlungsanforderung
2. Provider-Aufruf wird begrenzt
Timeout, Circuit Breaker und klarer Retry-Plan verhindern unkontrollierte Warteschlangen. Nicht jeder Fehler darf automatisch wiederholt werden.
3. Payment speichert Ergebnis und Outbox
Autorisierung oder Ablehnung wird zusammen mit einem neuen Outbox-Ereignis atomar gespeichert.
4. Saga setzt Prozess fort
Bei Erfolg wird Order bezahlt; bei Ablehnung wird sie in einen erklärbaren Fehlerzustand gesetzt. Inventory kann eine Reservierung kompensieren.
5. Unklare Provider-Antwort wird aufgeklärt
Bei Timeout ist nicht sicher, ob der Provider gebucht hat. Payment fragt mit derselben Idempotency-ID nach, bevor eine neue Zahlung ausgelöst wird.
Architekturentscheidung
CommerceOne verwendet keine verteilte ACID-Transaktion. Lokale Transaktionen, Ereignisse, idempotente Provider-Aufrufe und explizite Kompensation machen den Zustand sichtbar und wiederherstellbar.
Lernkontrolle
Warum ist eine Kompensation nicht dasselbe wie ein Datenbank-Rollback?
Antwort selbst formulieren
Weiterlernen
Öffne markierte Fachbegriffe direkt im Text oder untersuche ihre Beziehungen im Knowledge Graph.