Wie werden RPO und RTO gewählt?
RPO und RTO müssen aus Geschäftsschaden und Wiederanlaufkosten abgeleitet werden. Null Datenverlust und Sofort-Recovery sind selten wirtschaftlich.
Bestellung vom Klick bis zur Bestätigung
Der Ablauf ähnelt einer Bestellung in einem gut organisierten Geschäft: Zuerst wird die Bestellung aufgenommen, dann fachlich geprüft, gespeichert und anschließend an Lager, Zahlung und Benachrichtigung weitergereicht. Nicht jeder Schritt muss in derselben Transaktion stattfinden.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Kunde klickt „Bestellen“
- Gateway nimmt Anfrage an
- Order Service prüft Regeln
- PostgreSQL speichert Order und Outbox
- Kafka verteilt Event
- Inventory und Payment reagieren
- Notification informiert den Kunden.
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
Ein Datenverlust oder regionaler Ausfall darf den Geschäftsbetrieb nur innerhalb akzeptierter Grenzen beeinträchtigen.
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: Business-basierte Ziele
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: Technisch maximaler Schutz
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: Business-basierte Ziele – aber nur unter den dokumentierten Voraussetzungen. Die Alternative Technisch maximaler Schutz 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 Business-basierte Ziele 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.