Kapitel II · Bereich 06 von 12
Die Frage an unseren ShopWem gehören die Bestelltabellen, wenn alle Module eine Datenbank teilen?
Hier findest du Ansätze für Datenhoheit, Speicherung und verlässliche Zustandsänderungen.
9 Bausteine
Hier anfangenDatenhoheitWem gehört er, und wo liegt er?
Bestellung besitzt ihre Tabellen; Produktsuche und Bilder liegen in passenden Speichern.
Was muss gemeinsam stimmen?
B-1042 und Outbox-Eintrag committen gemeinsam; als getrennte Dienste bräuchten Lager und Zahlung eine Saga.
Wie wird er verteilt und beschleunigt?
Lesereplikat für den Kundenservice, Partitionen nach Kunden-ID, Cache im Katalog.
Bekannte Namen – und wo sie stecken
Datenhoheit klärt, wer Regeln und Zustände verantwortet. Persistenz und Polyglot Persistence wählen die Speicher, Partitionierung teilt sie. Transaktionen und Konsistenz regeln Änderungen, Saga verbindet mehrere; Replikation und Caching halten Kopien bereit.
Hier klärst du im Shop, wem die Bestelltabellen gehören, was bei einer Änderung gemeinsam gelten muss und wie Daten verteilt und beschleunigt werden. So weißt du, wer Zustände ändern darf. Jeder Baustein zeigt sein Thema an unserem Shop.
Das lernst duDu kannst für Bestell-, Zahlungs- und Bestandsdaten jeweils genau ein verantwortliches Modul bestimmen.
Im ShopIm modularen Monolithen liegen Tabellen in einer Datenbank, bleiben aber fachlich einzelnen Modulen zugeordnet. Gemeinsame Speicherung hebt die Datenhoheit nicht auf.
Datenhoheit öffnenDas lernst duDu kannst für Bestellschreiben und Produktsuche ein Speichermodell anhand des Zugriffsmusters auswählen.
Im ShopBestellungen benötigen atomare Status- und Positionsänderungen. Die Produktsuche braucht flexible Volltextabfragen über Beschreibungen und Kategorien.
SQL & NoSQL öffnenDas lernst duDu kannst bestimmen, welche Bestelländerungen atomar in eine lokale Transaktion gehören.
Im ShopDer Checkout speichert Auftrag B-1042 mit Position P-7 und Bestellsumme in der Shop-Datenbank. Die Belastung beim Zahlungsanbieter ist ein externer Aufruf.
Transaktionsgrenzen öffnenDas lernst duDu kannst für Bestandsreservierung und Kundenübersicht unterschiedliche Sichtbarkeitszusagen formulieren.
Im ShopDie Lagerreservierung muss aktuellen Bestand verbindlich prüfen. Eine Kundenservice-Übersicht darf den neuen Versandstatus wenige Sekunden später zeigen.
Konsistenzmodelle öffnenDas lernst duDu kannst erklären, warum ein Lesereplikat unmittelbar nach einer Änderung einen älteren Bestellstatus zeigen kann.
Im ShopVariante: Der Shop nutzt für Kundenservice-Abfragen ein Lesereplikat der Bestelldatenbank, um viele Abfragen vom Schreibsystem fernzuhalten.
Replikation öffnenDas lernst duDu kannst einen Partitionsschlüssel wählen und eine partitionsübergreifende Abfrage erkennen.
Im ShopVariante: Bei stark gewachsenem Bestellvolumen verteilt der Shop Bestellungen nach Kunden-ID auf drei Partitionen. Die übrigen Module bleiben im modularen Monolithen.
Partitionierung öffnenDas lernst duDu kannst für Produktbeschreibung, Preis und Bestand jeweils eine Aktualitätsregel festlegen.
Im ShopDer Katalog zeigt Produkttexte, Preise und verfügbare Mengen. Diese Werte ändern sich unterschiedlich oft und haben unterschiedliche Folgen bei Veraltung.
Caching öffnenDas lernst duDu kannst jedem eingesetzten Speicher eine eigenständige Aufgabe und eine maßgebliche Quelle zuordnen.
Im ShopVariante: Der gewachsene Shop hält Bestellungen relational, sucht Produkte in einem Suchindex und speichert Produktbilder in einem Objektspeicher. Der Shop bleibt fachlich modular aufgebaut.
Polyglot Persistence öffnenDas lernst duDu kannst für einen fehlgeschlagenen Bestellablauf die lokalen Schritte und passende Kompensationen anordnen.
Im ShopVariante: Lager und Zahlung laufen als getrennte Dienste, weil unabhängiger Betrieb fachlich begründet wurde. Bestellung koordiniert die Reservierung und den extern angebundenen Zahlungsanbieter.
Saga öffnenDiese Bereiche hängen fachlich direkt mit Daten & Zustand zusammen.