Zwölf nachvollziehbare Architekturentscheidungen mit Alternativen, Kosten, Risiken, Einsatzgrenzen und CommerceOne-Konsequenzen. Keine Technologie wird pauschal empfohlen.
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.
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
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.
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.
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.
Kubernetes lohnt sich bei vielen Services, standardisiertem Betrieb, hoher Änderungsrate und eigener Plattformkompetenz. Für kleine Systeme ist eine einfachere Runtime oft wirtschaftlicher.
Empfehlung: Kubernetes
Entscheidung öffnenKafka 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.
Empfehlung: Kafka
Entscheidung öffnenPostgreSQL ist der Standard, wenn Konsistenz, Beziehungen und flexible Abfragen wichtig sind. NoSQL oder Event Store sind Spezialentscheidungen, keine automatischen Modernisierungen.
Empfehlung: PostgreSQL
Entscheidung öffnenGitOps verbessert Nachvollziehbarkeit und Drift-Erkennung. Direktdeployment ist einfacher, wenn Team, Plattform und Änderungsvolumen klein sind.
Empfehlung: GitOps
Entscheidung öffnenHelm ist stark bei wiederverwendbaren Paketen und parametrisierten Releases. Kustomize bleibt näher am Kubernetes-YAML und ist oft leichter prüfbar.
Empfehlung: Helm
Entscheidung öffnenManaged Services reduzieren Routinebetrieb, schaffen aber Kosten, Abhängigkeiten und Plattformgrenzen. Eigenbetrieb lohnt sich nur mit klarer Kompetenz, Skalierung oder regulatorischem Grund.
Empfehlung: Managed Service
Entscheidung öffnenOIDC zentralisiert Login und Vertrauensregeln. Lokale Sessions können bei kleinen, abgeschlossenen Anwendungen einfacher und risikoärmer sein.
Empfehlung: Zentraler Identity Provider
Entscheidung öffnenSynchron ist verständlich und unmittelbar, asynchron entkoppelt Zeit und Verfügbarkeit. Enterprise-Systeme benötigen meist eine bewusst begrenzte Kombination.
Empfehlung: Gemischtes Modell
Entscheidung öffnenEin modularer Monolith minimiert verteilte Komplexität. Microservices sind sinnvoll, wenn unabhängige Skalierung, Teamschnitt oder Release-Autonomie den Aufwand rechtfertigen.
Empfehlung: Modularer Monolith
Entscheidung öffnenRetries helfen nur bei vorübergehenden Fehlern. Circuit Breaker begrenzt Schaden; Queue entkoppelt zeitlich. Die Fehlerklasse entscheidet.
Empfehlung: Policy je Fehlerklasse
Entscheidung öffnenMetriken, Logs und Traces sollten von Benutzerwirkung und Diagnosebedarf ausgehen. Vollständige Telemetrie überall erzeugt Kosten und Rauschen.
Empfehlung: Service-Level-Telemetrie
Entscheidung öffnenRPO und RTO müssen aus Geschäftsschaden und Wiederanlaufkosten abgeleitet werden. Null Datenverlust und Sofort-Recovery sind selten wirtschaftlich.
Empfehlung: Business-basierte Ziele
Entscheidung öffnenJede Empfehlung ist kontextabhängig. Ändern sich Teamgröße, regulatorische Anforderungen, Lastprofil oder Betriebsmodell, muss die Entscheidung erneut bewertet werden.
Policy-gesteuerte, begrenzte und auditierbare Resilience-Experimente.
Entscheidung öffnenInternal Developer Platform mit Contracts, Capabilities und Outcome-Metriken.
Entscheidung öffnenDirekte Kosten, Shared Costs, Showback und Unit Economics.
Decision öffnenNeu in V7.19: vollständig integrierter Lern- und Betriebsinhalt.
Domain Ownership mit zentralen Plattform-Guardrails verbinden.
ÖffnenDecision Rights nach Risiko und Reversibilität.
Entscheidung öffnenFöderierte Modellverantwortung auf einer zentral governten Plattform.
Entscheidung öffnenArchitecture Decision.
Entscheidung öffnenArchitecture Decision.
Entscheidung öffnenArchitecture Decision.
Entscheidung öffnenArchitecture Decision.
Entscheidung öffnenArchitecture Decision.
Entscheidung öffnen