18. Apr. 2025·8 Min
Jim Gray, Transaktionsverarbeitung und warum ACID noch wichtig ist
Ein praktischer Blick auf Jim Grays Ideen zur Transaktionsverarbeitung und wie ACID-Prinzipien Banken, Commerce- und SaaS-Systeme zuverlässig halten.
Ein praktischer Blick auf Jim Grays Ideen zur Transaktionsverarbeitung und wie ACID-Prinzipien Banken, Commerce- und SaaS-Systeme zuverlässig halten.
Jim Gray war ein Informatiker, der sich eine überraschend einfache Frage stellte: wenn viele Leute gleichzeitig ein System benutzen — und Ausfälle unvermeidbar sind — wie hältst du die Ergebnisse richtig?
Seine Arbeit zur Transaktionsverarbeitung half, Datenbanken von „manchmal korrekt, wenn du Glück hast“ zu Infrastruktur zu machen, auf der man tatsächlich ein Geschäft aufbauen kann. Die von ihm verbreiteten Ideen — insbesondere die ACID-Eigenschaften — tauchen überall auf, selbst wenn du das Wort „Transaktion" nie in einer Produktbesprechung gehört hast.
Ein vertrauenswürdiges System ist eines, bei dem Nutzer sich auf Ergebnisse verlassen können, nicht nur auf Bildschirme.
Mit anderen Worten: korrekte Salden, korrekte Bestellungen und keine fehlenden Einträge.
Auch moderne Produkte mit Queues, Microservices und Drittanbieter-Zahlungen hängen an entscheidenden Stellen von Transaktionsdenken ab.
Wir halten die Konzepte praktisch: was ACID schützt, wo Bugs sich gerne verstecken (Isolation und Nebenläufigkeit) und wie Logs und Recovery Ausfälle überlebbar machen.
Wir behandeln auch moderne Kompromisse — wo du ACID-Grenzen ziehst, wann verteilte Transaktionen sinnvoll sind und wann Muster wie Sagas, Retries und Idempotenz dir „gut genug“ Konsistenz geben, ohne zu überengineering.
Eine Transaktion ist eine Möglichkeit, eine mehrstufige Geschäftsaktion als eine einzelne „ja/nein“-Einheit zu behandeln. Wenn alles klappt, commitest du. Wenn etwas schiefgeht, rollst du zurück, als wäre nichts passiert.
Stell dir vor, du überweist 50 $ vom Giro- aufs Sparkonto. Das sind nicht nur eine Änderung, sondern mindestens zwei:
Wenn dein System nur „Ein-Schritt-Updates" macht, könnte es erfolgreich die Abbuchung durchführen und dann vor der Gutschrift fehlschlagen. Jetzt fehlt dem Kunden 50 $ — und die Support-Tickets beginnen.
Ein typischer Checkout umfasst das Anlegen der Bestellung, das Reservieren von Inventar, die Autorisierung der Zahlung und das Erfassen des Belegs. Jeder Schritt berührt unterschiedliche Tabellen (oder sogar unterschiedliche Services). Ohne Transaktionsdenken kannst du eine Bestellung mit dem Status „bezahlt" haben, aber kein reserviertes Inventar — oder Inventar reservieren für eine Bestellung, die nie angelegt wurde.
Fehler passieren selten zu bequemen Zeitpunkten. Häufige Bruchstellen sind:
Transaktionsverarbeitung existiert, um ein einfaches Versprechen zu geben: entweder treten alle Schritte einer Geschäftsaktion zusammen in Kraft, oder keiner. Dieses Versprechen ist die Grundlage für Vertrauen — egal ob du Geld verschiebst, eine Bestellung aufgibst oder einen Abo-Plan änderst.
ACID ist eine Checkliste von Schutzmechanismen, die eine „Transaktion" vertrauenswürdig machen. Es ist kein Marketingbegriff, sondern eine Reihe von Zusagen darüber, was passiert, wenn du wichtige Daten änderst.
Atomicity bedeutet, eine Transaktion wird entweder vollständig abgeschlossen oder hinterlässt keine Spur.
Denk an eine Überweisung: Du belastest Konto A um 100 $ und gutschreibst Konto B um 100 $. Wenn das System nach der Belastung aber vor der Gutschrift abstürzt, sorgt Atomicity dafür, dass die ganze Überweisung zurückgerollt wird (niemand „verliert" Geld in der Luft) oder vollständig abgeschlossen wird. Es gibt keinen gültigen Endzustand, in dem nur eine Seite passiert ist.
Consistency heißt, deine Datenregeln (Constraints und Invarianten) gelten nach jeder abgeschlossenen Transaktion.
Beispiele: Ein Saldo darf nicht negativ sein, wenn Überziehungen verboten sind; die Summe von Lastschriften und Gutschriften einer Überweisung muss übereinstimmen; ein Bestellgesamtpreis muss den Positionen plus Steuern entsprechen. Konsistenz ist teils Aufgabe der Datenbank (Constraints), teils der Anwendung (Business-Logik).
Isolation schützt dich, wenn mehrere Transaktionen gleichzeitig ablaufen.
Beispiel: Zwei Kunden versuchen, die letzte Einheit eines Artikels zu kaufen. Ohne richtige Isolation sehen beide „1 verfügbar" und beide können erfolgreich abschließen, sodass das Inventar bei -1 landet oder eine mühsame manuelle Korrektur nötig wird.
Durability bedeutet: Sobald du „committed" siehst, verschwindet das Ergebnis nicht nach einem Crash oder Stromverlust. Wenn der Beleg sagt, die Überweisung ist erfolgreich, muss das Ledger das nach einem Neustart weiterhin zeigen.
„ACID" ist kein einzelner Ein/Aus-Schalter. Verschiedene Systeme und Isolationsebenen liefern unterschiedliche Garantien, und oft wählst du, welche Schutzmechanismen für welche Operationen gelten.
Wenn Leute über „Transaktionen" sprechen, ist Banking das klarste Beispiel: Nutzer erwarten, dass Salden korrekt sind — immer. Eine Banking-App kann etwas langsamer sein; sie darf nicht falsch sein. Ein falscher Saldo kann Überziehungsgebühren, verpasste Zahlungen und eine lange Kette von Folgearbeiten auslösen.
Eine einfache Überweisung ist keine Einzelaktion — sie besteht aus mehreren Schritten, die zusammen gelingen oder scheitern müssen:
ACID-Denken behandelt das als eine Einheit. Wenn irgendein Schritt fehlschlägt — Netzwerkaussetzer, Service-Crash, Validierungsfehler — darf das System nicht „teilweise gelingen". Ansonsten fehlen Geldbeträge auf A ohne Gutschrift auf B, oder Geld erscheint auf B ohne entsprechende Belastung, oder es gibt keine Prüfspur, die erklärt, was passiert ist.
In vielen Produkten lässt sich eine kleine Inkonsistenz im nächsten Release beheben. Im Banking wird „später reparieren" zu Streitfällen, regulatorischem Risiko und manuellen Prozessen. Support-Tickets schießen in die Höhe, Ingenieure werden in Incident-Calls gezogen und Operations-Teams verbringen Stunden mit Abgleichen fehlerhafter Datensätze.
Selbst wenn du die Zahlen korrigieren kannst, musst du immer noch die Historie erklären können.
Deshalb verlassen sich Banken auf Ledger und append-only Aufzeichnungen: statt Historie zu überschreiben, zeichnen sie eine Folge von Last- und Gutschriften auf, die aufgehen. Unveränderliche Logs und klare Audit-Traces machen Recovery und Untersuchung möglich.
Reconciliation — der Vergleich unabhängiger Wahrheiten — wirkt als Rückversicherung, wenn etwas schiefgeht, und hilft Teams zu bestimmen, wann und wo eine Abweichung entstand.
Korrektheit schafft Vertrauen. Sie reduziert auch das Support-Aufkommen und beschleunigt die Problemlösung: wenn ein Problem auftritt, erlaubt ein sauberer Audit-Trail und konsistente Ledger-Einträge die Frage „was ist passiert?“ schnell zu beantworten und zu beheben, ohne Rätselraten.
E-Commerce wirkt simpel, bis du Spitzenlast erreichst: derselbe letzte Artikel liegt in zehn Warenkörben, Kunden laden die Seite neu und dein Zahlungsanbieter time- outet. Hier zeigt sich Jim Grays Transaktionsdenke in praktischen, unspektakulären Wegen.
Ein typischer Checkout berührt mehrere Zustände: Inventar reservieren, Bestellung anlegen und Zahlung einziehen. Unter hoher Nebenläufigkeit kann jeder Schritt für sich korrekt sein und trotzdem ein schlechtes Gesamtergebnis produzieren.
Wenn du Inventar ohne Isolation dekrementierst, können zwei Checkouts „1 übrig" lesen und beide erfolgreich sein — Hallo Overselling. Wenn du die Zahlung einziehst und dann die Bestellung nicht erstellst, hast du den Kunden belastet ohne etwas zu liefern.
ACID hilft vor allem an der Datenbankgrenze: wickle das Anlegen der Bestellung und die Inventarreservierung in einer einzigen Datenbanktransaktion ab, damit sie entweder beide committen oder beide zurückrollen. Du kannst Korrektheit auch mit Constraints durchsetzen (z. B. „Inventar darf nicht unter 0 fallen"), sodass die DB unmögliche Zustände ablehnt, selbst wenn Anwendungslogik versagt.
Netzwerke verlieren Antworten, Nutzer klicken doppelt und Hintergrundjobs wiederholen. Deshalb ist „exactly once" über Systeme hinweg schwer. Das Ziel wird: höchstens einmal bei Geldbewegungen, und sichere Retries überall sonst.
Verwende Idempotency-Keys bei deinem Zahlungsanbieter und speichere einen dauerhaften Datensatz eines „payment intent", verknüpft mit deiner Bestellung. Selbst wenn dein Service erneut versucht, belastet er nicht doppelt.
Retouren, Teilrückerstattungen und Chargebacks sind Geschäftsfakten, keine Randfälle. Klare Transaktionsgrenzen erleichtern sie: du kannst jede Anpassung zuverlässig einer Bestellung, einer Zahlung und einem Audit-Trail zuordnen — sodass die Abstimmung erklärbar ist, wenn etwas schiefgeht.
SaaS-Geschäfte beruhen auf einem Versprechen: wofür der Kunde zahlt, das kann er sofort und vorhersehbar nutzen. Das klingt einfach, bis du Plan-Upgrades, Downgrades, anteilige Abrechnung, Rückerstattungen und asynchrone Zahlungsevents mischst. ACID-ähnliches Denken hilft, „Abrechnungswahrheit" und „Produktwahrheit" in Einklang zu halten.
Eine Planänderung löst oft eine Kette von Aktionen aus: Rechnung erstellen/ändern, Proration erfassen, Zahlung einziehen (oder versuchen) und Berechtigungen aktualisieren (Features, Seats, Limits). Behandle diese als eine Einheit, bei der Teilerfolge inakzeptabel sind.
Wenn eine Upgrade-Rechnung erstellt wird, aber Berechtigungen nicht aktualisiert werden (oder umgekehrt), verlieren Kunden entweder Zugriff, den sie bezahlt haben, oder sie erhalten Zugriff ohne Bezahlung.
Ein praktisches Muster ist, die Abrechnungsentscheidung (neuer Plan, Wirksamkeitsdatum, Proration-Zeilen) und die Berechtigungsentscheidung zusammen zu persistieren und dann nachgelagerte Prozesse von diesem committeden Datensatz auszuführen. Kommt die Zahlungsbestätigung später, kannst du den Zustand sicher weiterbewegen, ohne die Historie umzuschreiben.
In Multi-Tenant-Systemen ist Isolation nicht akademisch: die starke Aktivität eines Kunden darf den anderen nicht blockieren oder korrumpieren. Verwende tenant-spezifische Schlüssel, klare Transaktionsgrenzen pro Mandant und sorgfältig gewählte Isolationsebenen, sodass ein Ansturm von Erneuerungen für Mandant A nicht zu inkonsistenten Reads für Mandant B führt.
Support-Tickets beginnen meist mit „Warum wurde mir etwas berechnet?" oder „Warum kann ich nicht auf X zugreifen?" Führe ein append-only Audit-Log darüber, wer was wann geändert hat (User, Admin, Automation) und verknüpfe es mit Rechnungen und Berechtigungsübergängen.
Das verhindert stilles Auseinanderlaufen — wo Rechnungen „Pro" anzeigen, Berechtigungen aber noch „Basic" widerspiegeln — und macht Abstimmung zu einer Abfrage, nicht zu einer Untersuchung.
Isolation ist das „I" in ACID, und hier scheitern Systeme oft auf subtile, teure Weise. Die Kernidee ist einfach: viele Nutzer handeln gleichzeitig, aber jede Transaktion sollte sich so verhalten, als hätte sie allein ausgeführt.
Stell dir ein Geschäft mit zwei Kassierern und einem letzten Artikel im Regal vor. Wenn beide Kassierer gleichzeitig den Bestand prüfen und jeweils „1 verfügbar" sehen, könnten sie ihn beide verkaufen. Nichts ist abgestürzt, aber das Ergebnis ist falsch — wie ein Double-Spend.
Datenbanken stehen vor demselben Problem, wenn zwei Transaktionen dieselben Zeilen gleichzeitig lesen und ändern.
Die meisten Systeme wählen ein Isolation-Level als Kompromiss zwischen Sicherheit und Durchsatz:
Wenn ein Fehler finanziellen Verlust, rechtliche Folgen oder für Kunden sichtbare Inkonsistenzen erzeugt, neige zu stärkerer Isolation (oder explizitem Locking/Constraints). Wenn der Worst Case ein temporärer UI-Fehler ist, kann ein schwächeres Level akzeptabel sein.
Höhere Isolation kann Durchsatz senken, weil die DB mehr Koordination leisten muss — Warten, Sperren oder Abbrechen/Neuversuche, um unsichere Interleavings zu verhindern. Die Kosten sind real, aber genauso real sind die Kosten falscher Daten.
Wenn ein System abstürzt, ist die wichtigste Frage nicht „warum ist es abgestürzt?" sondern „in welchem Zustand sollten wir nach dem Neustart sein?" Jim Grays Arbeit zur Transaktionsverarbeitung machte die Antwort praktisch: Durability erzielt man durch diszipliniertes Logging und Recovery.
Ein Transaktionslog (oft WAL genannt) ist ein append-only Protokoll von Änderungen. Es ist zentral für die Wiederherstellung, weil es die Absicht und Reihenfolge von Updates bewahrt, auch wenn die Datenbankdateien beim Stromausfall mitten im Schreiben waren.
Beim Neustart kann die Datenbank:
Das ist der Grund, warum „wir haben committed" auch dann wahr bleiben kann, wenn der Server nicht sauber heruntergefahren wurde.
Write-Ahead Logging bedeutet: das Log wird auf dauerhaften Speicher geschrieben, bevor die Datenpages geschrieben werden dürfen. Praktisch ist ein „Commit" daran gebunden, dass die relevanten Log-Einträge sicher auf dem Datenträger (oder anders dauerhaft) sind.
Passiert ein Crash direkt nach dem Commit, kann die Recovery das Log abspielen und den committeten Zustand rekonstruieren. Passiert der Crash vor dem Commit, hilft das Log beim Zurückrollen.
Ein Backup ist ein Snapshot (eine Kopie zu einem Zeitpunkt). Logs sind eine Historie (was sich seit diesem Snapshot geändert hat). Backups helfen bei katastrophalem Verlust (fehlerhafte Deploys, gelöschte Tabelle, Ransomware). Logs helfen, kürzliches committetes Arbeiten wiederherzustellen und unterstützen Point-in-Time-Recovery: Backup zurückspielen und dann Logs bis zu einem gewählten Moment abspielen.
Ein Backup, das du nie wiederhergestellt hast, ist Hoffnung, kein Plan. Plane regelmäßige Wiederherstellungsübungen in einer Staging-Umgebung, überprüfe die Datenintegrität und messe, wie lange die Recovery tatsächlich dauert. Wenn sie nicht deinen RTO/RPO-Anforderungen entspricht, passe Aufbewahrung, Log-Versand oder Backup-Frequenz an, bevor ein Vorfall die Lektion aufzwingt.
ACID funktioniert am besten, wenn eine Datenbank als "Single Source of Truth" für eine Transaktion dienen kann. Sobald eine Geschäftsaktion mehrere Services streift (Payments, Inventar, E-Mail, Analytics), bist du in verteilten Systemen — dort sehen Ausfälle nicht mehr wie saubere "Erfolg"- oder "Fehler"-Fälle aus.
In einer verteilten Architektur musst du partielle Ausfälle annehmen: ein Service commitet, während ein anderer abstürzt, oder ein Netzwerkproblem verschleiert das tatsächliche Ergebnis. Noch schlimmer: Timeouts sind zweideutig — ist die andere Seite ausgefallen oder nur langsam?
Diese Ungewissheit erzeugt doppelte Abbuchungen, Überverkäufe und fehlende Berechtigungen.
Two-Phase Commit versucht, mehrere Datenbanken wie eine einzige committen zu lassen.
Teams vermeiden 2PC oft, weil es langsam sein kann, Locks länger hält (Durchsatz leidet) und der Koordinator zum Engpass wird. Es koppelt Systeme fest: alle Teilnehmer müssen das Protokoll sprechen und hochverfügbar bleiben.
Ein gängiger Ansatz ist, ACID-Grenzen klein zu halten und die Cross-Service-Arbeit explizit zu managen:
Setze die stärksten Garantien (ACID) innerhalb einer einzelnen Datenbank, wann immer möglich, und behandle alles jenseits dieser Grenze als Koordination mit Retries, Reconciliation und klarer Antwort auf „was passiert, wenn dieser Schritt fehlschlägt?".
Fehler sehen selten nach einem sauberen „es ist nicht passiert" aus. Häufiger hat eine Anfrage teilweise Erfolg, der Client time- outet, und jemand (Browser, Mobile App, Job Runner oder Partner) wiederholt.
Ohne Schutzmechanismen erzeugen Retries die fiesesten Bugs: korrekt aussehender Code, der gelegentlich doppelt abrechnet, doppelt liefert oder doppelt Zugänge freigibt.
Idempotenz ist die Eigenschaft, dass die wiederholte Ausführung derselben Operation das gleiche Endergebnis hat wie einmalige Ausführung. Für Nutzersysteme heißt das: sichere Retries ohne doppelte Effekte.
Eine Faustregel: GET ist von Natur aus idempotent; viele POST-Operationen sind es nicht, es sei denn, du gestaltest sie so.
Kombiniere typischerweise mehrere Mechanismen:
Idempotency-Key: ...). Der Server speichert das Ergebnis unter diesem Key und liefert bei Wiederholungen dasselbe zurück.order_id, ein Abo pro account_id + plan_id).Diese funktionieren am besten, wenn die Unique-Prüfung und die Wirkung in derselben DB-Transaktion leben.
Ein Timeout bedeutet nicht, dass die Transaktion zurückgerollt wurde; sie könnte committed haben, während die Antwort verloren ging. Deshalb muss Retry-Logik davon ausgehen, dass der Server möglicherweise erfolgreich war.
Ein gängiges Muster ist: schreibe zuerst einen Idempotency-Datensatz (oder sperre ihn), führe die Seiteneffekte aus und markiere ihn dann als abgeschlossen — alles innerhalb einer Transaktion, wenn möglich. Wenn du nicht alles in eine Transaktion packen kannst (z. B. einen externen Payment-Gateway-Aufruf), persistiere eine dauerhafte „Intent"-Zeile und gleiche später ab.
Wenn Systeme „wackelig" wirken, ist die Wurzel oft fehlendes Transaktionsdenken. Typische Symptome: Phantom-Bestellungen ohne zugehörige Zahlung, negatives Inventar nach konkurrierenden Checkouts und nicht übereinstimmende Summen in Ledger, Rechnungen und Analytics.
Beginne damit, deine Invarianten aufzuschreiben — die Fakten, die immer wahr sein müssen. Beispiele: „Inventar fällt nie unter Null", „eine Bestellung ist entweder unpaid oder paid (nicht beides)", „jede Saldoänderung hat einen passenden Ledger-Eintrag".
Definiere dann Transaktionsgrenzen um die kleinste Einheit, die atomar sein muss, um diese Invarianten zu schützen. Wenn eine Benutzeraktion mehrere Zeilen/Tabellen berührt, entscheide, was zusammen committen muss und was sicher verzögert werden kann.
Wähle schließlich, wie du Konflikte unter Last behandelst:
Nebenläufigkeits-Bugs tauchen selten in Happy-Path-Tests auf. Füge Tests hinzu, die Druck erzeugen:
Du kannst nicht schützen, was du nicht misst. Nützliche Signale sind Deadlocks, Lock-Wartezeiten, Rollback-Raten (insbesondere Peaks nach Deploys) und Abstimmungsdifferenzen zwischen Source-of-Truth-Tabellen (Ledger vs. Balances, Orders vs. Payments). Diese Metriken warnen oft Wochen bevor Kunden „fehlendes" Geld oder Inventar melden.
Jim Grays bleibender Beitrag war nicht nur eine Eigenschaftsliste, sondern ein gemeinsames Vokabular für „was darf nicht schiefgehen". Wenn Teams die benötigte Zusicherung benennen können (Atomicity, Consistency, Isolation, Durability), werden Debatten über Korrektheit handhabbar: aus vagen „das sollte zuverlässig sein"-Aussagen werden konkrete Anforderungen („dieses Update muss atomar mit dieser Abbuchung sein").
Nutze vollständige Transaktionen, wenn ein Nutzer ein einzelnes, eindeutiges Ergebnis erwarten würde und Fehler teuer sind:
Hier verschiebt Optimierung auf Kosten von Garantien oft die Arbeit in Support-Tickets, manuelle Abstimmung und verlorenes Vertrauen.
Lockere Garantien, wenn temporäre Inkonsistenz akzeptabel und leicht zu heilen ist:
Der Trick ist, eine klare ACID-Grenze um die Source of Truth zu ziehen und alles andere dahinter herlaufen zu lassen.
Wenn du diese Flows prototypst (oder eine Legacy-Pipeline neu baust), hilft ein Stack, der Transaktionen und Constraints als erstklassig behandelt. Zum Beispiel kann Koder.ai eine React-Frontend plus Go + PostgreSQL-Backend aus einem einfachen Chat generieren — ein praktischer Weg, um früh echte Transaktionsgrenzen (inklusive Idempotency-Records, Outbox-Tabellen und rollback-sicheren Workflows) aufzubauen, bevor du in ein vollständiges Microservices-Setup investierst.
Wenn du mehr Muster und Checklisten möchtest, verlinke diese Erwartungen von /blog. Wenn du Zuverlässigkeits-Expectations nach Stufen anbietest, mache sie auf /pricing explizit, damit Kunden wissen, welche Korrektheitsgarantien sie kaufen.
Jim Gray war ein Informatiker, der Transaktionsverarbeitung praktisch und verständlich machte. Sein Vermächtnis ist die Denkweise, dass wichtige mehrstufige Aktionen (Geldbewegungen, Checkout, Abo-Änderungen) auch bei Nebenläufigkeit und Ausfällen korrekte Ergebnisse liefern müssen.
In Produktbegriffen: weniger „Rätselzustände“, weniger Nacharbeiten bei der Abstimmung und klare Zusagen, was committed wirklich bedeutet.
Eine Transaktion fasst mehrere Änderungen zu einer einzigen Alles-oder-nichts-Einheit zusammen. Du commitest, wenn alle Schritte gelingen; du rollst zurück, wenn irgendetwas fehlschlägt.
Typische Beispiele:
ACID ist eine Reihe von Zusicherungen, die Transaktionen vertrauenswürdig machen:
Es ist kein einziger Schalter — man wählt, welche Garantien wo erforderlich sind.
Die meisten „tritt nur in Produktion auf“-Bugs entstehen durch schwache Isolation unter Last.
Gängige Fehlerbilder:
Praktische Gegenmaßnahme: wähle das Isolation-Level nach dem Geschäftsrisiko und sichere es mit Constraints oder Locks ab, wo nötig.
Beginne damit, Invarianten in einfachem Deutsch zu formulieren (was muss immer wahr sein), und setze dann Transaktionsgrenzen um die kleinstmögliche Einheit, die diese Invarianten schützt.
Mechanismen, die gut zusammenarbeiten:
Betrachte Constraints als Sicherheitsnetz, wenn Anwendungslogik bei Nebenläufigkeit Fehler macht.
Write-ahead Logging (WAL) ist der Mechanismus, mit dem Datenbanken ein "Commit" gegen Abstürze sicher machen.
Operativ:
Deshalb gilt bei gutem Design: , selbst nach einem Stromausfall.
Backups sind punktuelle Snapshots; Logs sind die Historie seit diesem Snapshot.
Praktische Wiederherstellungsstrategie:
Wenn du noch nie aus einem Backup wiederhergestellt hast, hast du noch keinen echten Plan.
Verteilte Transaktionen versuchen, mehrere Systeme wie eins committen zu lassen, aber partielle Ausfälle und uneindeutige Timeouts machen das schwierig.
Two-Phase Commit (2PC) bringt typischerweise mit sich:
Nutze 2PC nur, wenn du echte Cross-System-Atomizität brauchst und die operative Komplexität tragen kannst.
Bevorzuge kleine lokale ACID-Grenzen und explizite Koordination zwischen Services.
Gängige Muster:
Das liefert vorhersagbares Verhalten bei Retries und Ausfällen, ohne jeden Ablauf in eine globale Sperre zu verwandeln.
Geh davon aus, dass ein Timeout bedeuten kann „es hat erfolgreich gearbeitet, aber du hast die Antwort nicht gesehen“. Gestalte Retries sicher.
Mechanismen gegen Duplikate:
Best Practice: Mach die Dedupe-Prüfung und die Zustandsänderung wenn möglich in derselben DB-Transaktion.