PostgreSQL, NoSQL oder Event Store?
PostgreSQL ist der Standard, wenn Konsistenz, Beziehungen und flexible Abfragen wichtig sind. NoSQL oder Event Store sind Spezialentscheidungen, keine automatischen Modernisierungen.
Event Flow verständlich gelesen
Ein Event ist mit einem eingeschriebenen Brief vergleichbar: Der Producer schreibt eine Nachricht, Kafka ordnet sie einem Topic und einer Partition zu, und Consumer lesen sie in ihrer eigenen Geschwindigkeit. Offsets markieren, bis wohin ein Consumer gekommen ist.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Producer erstellt Event
- Schema wird geprüft
- Broker speichert Event
- Partition bestimmt Reihenfolge
- Consumer Group verteilt Arbeit
- Consumer bestätigt Offset
- Telemetrie misst Lag und Fehler.
Fachlicher Ablauf
Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.
- 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: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.
Technischer Ablauf
Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.
- 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 Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.
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
Order benötigt konsistente Zustände, Suchabfragen, Audit-Nachweise und verlässliche Wiederherstellung.
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: PostgreSQL
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: Dokumentdatenbank oder Event Store
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: PostgreSQL – aber nur unter den dokumentierten Voraussetzungen. Die Alternative Dokumentdatenbank oder Event Store 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 PostgreSQL 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.