Order und Payment benötigen andere Wiederherstellungsziele als ein Marketing-Dashboard. Ziele bestimmen Backup-Frequenz und Architektur.
CommerceOne Architekturgeschichte
Vom Backup zur nachgewiesenen Wiederherstellung
RPO, RTO, Restore-Test, Konsistenzprüfung und Wiederanlauf.
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. Geschäftsziel definiert RPO und RTO
2. Backup wird unabhängig gespeichert
Daten und notwendige Metadaten werden verschlüsselt, versioniert und gegen versehentliches Löschen geschützt.
3. Restore wird regelmäßig getestet
In einer isolierten Umgebung werden Datenbank, Schemas, Secrets und Konfiguration wiederhergestellt. Ein erfolgreicher Datei-Download ist noch kein erfolgreicher Restore.
4. Fachliche Konsistenz wird geprüft
Bestellungen, Zahlungen, Outbox und Kafka-Fortschritt werden gemeinsam betrachtet. Doppelte oder fehlende Folgeaktionen müssen beherrscht werden.
5. Wiederanlauf erfolgt kontrolliert
Producer und Consumer werden in definierter Reihenfolge aktiviert. Idempotenz schützt vor erneut verarbeiteten Events.
6. Nachweis wird dokumentiert
Zeit, Datenstand, Abweichungen und Maßnahmen werden als Restore-Test-Record festgehalten.
Architekturentscheidung
Ein Backup ist erst wertvoll, wenn CommerceOne die Wiederherstellung wiederholt, zeitlich gemessen und fachlich überprüft hat.
Lernkontrolle
Warum reicht ein technisch erfolgreicher Datenbank-Restore für die Freigabe noch nicht aus?
Antwort selbst formulieren
Weiterlernen
Öffne markierte Fachbegriffe direkt im Text oder untersuche ihre Beziehungen im Knowledge Graph.