Transaktionssysteme

Warum Transaktionssysteme einen besonderen Ansatz erfordern¶

Ein Transaktionssystem ist eine andere Kategorie von Software als CRUD-Anwendungen. Wenn eine Zahlung nur zur Haelfte durchgeht — Geld verlaesst ein Konto, kommt aber nicht auf dem anderen an — haben Sie ein Problem, das Kundenvertrauen und regulatorische Aufmerksamkeit kostet. Wir bauen Systeme, bei denen Konsistenz auf Architekturebene garantiert wird, nicht auf der „hoffentlich klappt es”-Ebene.

ACID in der Microservices-Welt¶

Im Monolithen ist ACID einfach — Datenbanktransaktion. In der Microservices-Architektur, wo eine Geschaeftsoperation durch 3-5 Services geht, braucht man einen anderen Ansatz.

Saga-Pattern: Verteilte Transaktion als Sequenz lokaler Transaktionen. Jeder Schritt hat eine kompensierende Aktion — wenn Schritt 3 fehlschlaegt, werden Schritte 1 und 2 kompensiert (Rollback). Zwei Ansaetze:

• Orchestrierung — Zentraler Orchestrator steuert den Ablauf. Einfacheres Debugging, klare Visualisierung.
• Choreografie — Services reagieren auf Events. Weniger Kopplung, aber schwierigeres Debugging.

Wir waehlen basierend auf Komplexitaet und Teamstruktur. Fuer kritische Finanzoperationen bevorzugen wir Orchestrierung — expliziter Ablauf, bessere Fehlerbehandlung.

Outbox-Pattern: Garantierte Event-Zustellung. Transaktion schreibt Daten + Event in dieselbe Datenbank (atomar). Poller oder CDC liest Events und sendet an Kafka. Keine verlorenen Events, keine Duplikate (idempotente Consumer).

High Availability & Disaster Recovery¶

Fuer Finanzsysteme ist Verfuegbarkeit nicht verhandelbar. Unser HA/DR-Design:

• Active-Passive mit automatischem Failover — Standby-Replikat in anderer AZ. Automatische Fehlererkennung (Health Checks alle 5s), Failover unter 30s. Synchrone Replikation fuer RPO = 0.
• Multi-AZ-Deployment — Services laufen in mindestens 2 Verfuegbarkeitszonen. Load Balancer leitet Traffic automatisch zu gesunden Instanzen.
• DR-Tests — Monatliche automatisierte Failover-Uebungen. Vierteljaehrlicher vollstaendiger DR-Test mit Business-Stakeholdern.
• Chaos Engineering — Zufaelliges Beenden von Instanzen in der Produktion (kontrolliert). Validierung, dass Failover tatsaechlich funktioniert.

Idempotenz und Deduplizierung¶

In einem verteilten System werden Anfragen wiederholt — Netzwerk-Timeout, Retry-Logik, Queue-Redelivery. Jeder Endpunkt muss idempotent sein:

• Idempotenzschluessel — Client sendet eindeutigen Schluessel mit jeder Anfrage. Doppelte Anfrage gibt dasselbe Ergebnis zurueck, ohne die Operation zu wiederholen.
• Dedup auf Kafka-Ebene — Exactly-once-Semantik mit transaktionalem Producer.
• At-least-once-Zustellung — Consumer sind idempotent, doppelte Verarbeitung ist sicher.

Audit-Trail und Compliance¶

Der Regulator will nicht hoeren „wir vertrauen darauf, dass es funktioniert”. Er braucht Daten:

• Unveraenderlicher Audit-Log — Append-only, kryptografisch signiert. Wer, was, wann, woher, warum.
• Event Sourcing fuer Schluesseldomaenen — Zustand wird aus Event-Historie berechnet. Vollstaendige Zustandsrekonstruktion zu jedem Zeitpunkt.
• Aufbewahrungsrichtlinien — Konfigurierbar pro Regulierung (7 Jahre fuer Finanztransaktionen, 10 Jahre fuer AML).
• Export fuer Audit — Strukturierte Reports, filterbar, exportierbar. Audit-bereit in Stunden, nicht Wochen.

Performance unter Last¶

Ein Zahlungssystem muss auch unter Last schnell sein. Unsere Optimierungen:

• Connection Pooling — PgBouncer fuer PostgreSQL, Connection-Wiederverwendung.
• Prepared Statements — Eliminierung von Parse-Overhead fuer wiederkehrende Abfragen.
• Indizes und Partitionierung — Transaktionstabellen nach Monat partitioniert. Archivierung alter Daten ohne Performance-Auswirkung.
• Read Replicas — Reporting und Analytics gehen auf Read Replica, nicht auf Primary.
• Caching — Redis fuer Hot Data (Kontosalden, Rate Limits). Cache-Invalidierung via Kafka-Events.

Ergebnis: 5000+ Transaktionen/Sekunde mit konsistenter Latenz (P99 < 500ms) auf Standardinfrastruktur.

Verwandt mit