Ein Bestellprozess läuft über Payments, Inventory und Shipping, jeweils mit eigener Datenbank. Wie hältst du das Ganze konsistent?

Du gibst die eine verteilte Transaktion auf und nutzt eine Saga: eine Folge lokaler Transaktionen, bei der jeder Schritt ein Event publisht, das den nächsten auslöst, und jeder Schritt eine kompensierende Aktion zum Rückgängigmachen hat. Konsistenz wird eventual, die Designarbeit besteht also darin zu entscheiden, was kompensiert, was wiederholt und was an einen Menschen eskaliert wird. Modelliere den Ablauf explizit, entweder choreografiert über Events oder koordiniert von einem Orchestrator.

Ein Two-Phase-Commit über drei Services und drei Datenbanken heißt, Locks über das Netzwerk zu halten, plus ein Koordinator, der beim Ausfall alles blockieren kann, das würde ich also nicht machen. Stattdessen wird der Ablauf eine Saga. Jeder Service macht seine eigene lokale Transaktion und emittiert ein Event, und jeder Schritt hat eine definierte Kompensation: kann Shipping nicht allozieren, geben wir die Inventory-Reservierung frei und erstatten oder stornieren die Zahlung. Wichtig ist, dass Kompensation eine fachliche Aktion ist und kein Rollback; eine Rückerstattung hinterlässt eine sichtbare Spur, und das ist korrekt so. Bei allem mit mehr als etwa drei Schritten nehme ich einen Orchestrator statt reiner Choreografie, denn bei Choreografie steht der tatsächliche Ablauf nirgendwo, und niemand kann beantworten, wo eine Bestellung hängt. Ein Orchestrator gibt mir eine State Machine, Timeouts pro Schritt und einen abfragbaren Status. Jeder Schritt ist idempotent und wird mit Backoff wiederholt, und alles, was die Retries aufbraucht, landet mit der Bestell-id in einer Operations-Queue, denn manche Fehler brauchen wirklich einen Menschen.