Mit keiner gemeinsamen Datenbank kannst du keine Service-übergreifenden JOINs oder einzelne ACID-Transaktionen verwenden. Du komponierst Daten und hältst sie konsistent mit API-Komposition, Replikation/CQRS-Lesemodellen und Events.
— ein Koordinator ruft jeden Service auf und setzt das Ergebnis zusammen:
// build an order view from three services
const order = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId); // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
Für komplexe Abfragen, verwalte ein Lesemodell (CQRS): ein Service abonniert Events und erstellt eine denormalisierte lokale Kopie, die er direkt abfragen kann.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Verwende das Saga-Muster — eine Folge von lokalen Transaktionen mit kompensierenden Aktionen — statt einer verteilten Transaktion.
| Ansatz | Vorteil | Nachteil |
|---|---|---|
| API-Komposition | Immer aktuell | Latenz, Fan-out, fehleranfällig |
| Repliziertes Lesemodell | Schnelle Lesevorgänge | Eventuelle Konsistenz |
| Saga | Kein 2PC erforderlich | Komplex, benötigt Kompensation |
Teile nicht einfach eine Tabelle, um einen Join einfach zu machen — das koppelt die Services wieder an. Akzeptiere eventuelle Konsistenz, wo das Geschäft es erlaubt.
Datenverwaltung ist der Ort, an dem Microservices wirklich schwierig werden, weil die leichten Werkzeuge (Joins, Transaktionen) bewusst nicht verfügbar sind.
Das Verständnis von Komposition, Lesemodellen und Sagas ist das, was es dir ermöglicht, Services unabhängig zu halten, ohne die Korrektheit zu verlieren.