Datenarchitekturen und Zustandsmanagement

Datenarchitekturen und Zustandsmanagement

0:00 Von allen Entscheidungen, die wir in diesem Seminar treffen, sind die über Daten die am schwersten umkehrbaren. Code lässt sich umschreiben. Ein Datenbestand mit Millionen von Buchungen, an dem drei Dienste hängen, lässt sich das nicht — nicht über Nacht und nicht ohne Betriebsunterbrechung. Deshalb geht es in diesem Modul nicht nur um Speichertechnologien, sondern vor allem um zwei Fragen: Wem gehören welche Daten, und wie streng muss deren Konsistenz eigentlich sein?

Datenarchitekturen und Zustandsmanagement

0:26 Vier Kapitel liegen vor uns. Zuerst die Speichermodelle und die Frage, wie man das passende auswählt, ohne in eine Produktdiskussion zu geraten. Dann Konsistenz — ACID, das CAP-Theorem und die Partitionierung. Danach die Muster für verteilte Daten: Saga, Outbox, CQRS und Event Sourcing. Und am Ende legen Sie für Kartenwerk fest, wer welchen Datenbestand besitzt.

Moderne Datenhaltung

0:51 Beginnen wir bei den Speichern selbst. Die Auswahl wirkt wie eine Produktentscheidung, ist aber eine Entwurfsentscheidung — und sie beginnt an einer ganz anderen Stelle, als die meisten denken. Der Begriff Polyglot Persistence klingt nach Beliebigkeit, meint aber das Gegenteil: eine bewusste Entscheidung für mehrere Speicher, weil ein einzelner die verschiedenen Zugriffsmuster nicht gut bedienen kann.

1:14 Entscheidend ist die Reihenfolge im letzten Satz. Zuerst das Muster — greife ich über einen Schlüssel zu, aggregiere ich, suche ich Volltext, brauche ich Ähnlichkeit, lese ich Zeitfenster? Und erst danach das Produkt. In der Praxis läuft es meistens umgekehrt: Das Produkt steht fest, und die Zugriffsmuster werden hineingebogen.

1:33 Diese Tabelle ist bewusst als Nachschlagehilfe gebaut: links der Bedarf, rechts das Modell. Für Kartenwerk würden Sie hier mehrere Zeilen brauchen — relational für Buchungen und Sitzplätze, weil dort strenge Transaktionen über mehrere Entitäten nötig sind, dazu ein Suchindex für die Veranstaltungssuche und vermutlich ein schneller Zwischenspeicher für die Sitzungsdaten.

1:54 Das ist der Normalfall. Die Fußzeile ergänzt zwei Modelle, die selten in solchen Tabellen auftauchen und eigene Kostenprofile haben: Objektspeicher und Zeitreihen. Und hier kommt die Bremse, die zu jeder Empfehlung für Polyglot Persistence gehört. Die ersten drei Punkte sind echte Gründe: auseinandergehende Zugriffsmuster, verschiedene Aufbewahrungsfristen, widersprüchliche Anforderungen an Antwortzeit und Durchsatz.

2:18 Der vierte Punkt ist die Regel, die den Rest zusammenhält: Solange ein Speicher die Ziele erfüllt, ist ein zweiter reiner Betriebsaufwand. Jeder zusätzliche Speicher will überwacht, gesichert, aktualisiert und im Bereitschaftsfall verstanden werden — von Menschen, die um drei Uhr nachts geweckt wurden. Der erste Punkt ist ein Fehler, den man erst bemerkt, wenn es zu spät ist: Der Suchindex wird zur führenden Datenquelle.

2:42 Suchindizes sind für schnelles Lesen gebaut, nicht für verlässliches Schreiben — sie werden neu aufgebaut, sie sind verzögert konsistent, und sie verlieren im Zweifel etwas. Der dritte Punkt führt uns direkt zum dritten Kapitel: Mehrere Dienste an einer Datenbank sind keine mehreren Dienste. Sie sind ein System mit verteilter Auslieferung und damit das Schlechteste aus beiden Welten.

Auswahl eines Datenmodells

3:04 Kommen wir zur Konsistenz. Hier liegen einige der hartnäckigsten Missverständnisse unserer Branche — allen voran eines über ein Theorem, das fast jeder zitiert und kaum jemand präzise wiedergibt. ACID kennen Sie. Interessant ist die zweite Hälfte dieser Definition: Wie weit reichen diese Zusagen? Relationale Systeme geben sie über mehrere Zeilen und Tabellen hinweg.

3:26 Nichtrelationale Systeme geben sie enger — pro Dokument, pro Zeile, pro Schlüssel — und gewinnen dafür horizontale Skalierbarkeit. Das ist kein Qualitätsunterschied, sondern ein Tauschgeschäft. Wenn Ihre Fachlichkeit Änderungen über mehrere Objekte hinweg atomar braucht, haben Sie damit bereits eine Vorentscheidung über das Modell getroffen.

3:47 Die mittlere Spalte ist die praktisch wichtigste. Bei einem Dokumentenspeicher ist ein Dokument atomar — was Sie also in einem Dokument zusammenfassen, können Sie gemeinsam ändern, und was Sie trennen, nicht. Damit wird der Schnitt Ihrer Dokumente zur Transaktionsgrenze. Das ist eine tiefgreifende Entwurfsentscheidung, die sich später nur mit Datenmigration korrigieren lässt.

4:09 Die rechte Spalte ergänzt eine zweite Dimension: Wird das Schema beim Schreiben erzwungen oder erst beim Lesen gedeutet? Beides hat Folgen für Änderungen über Jahre. Jetzt das Missverständnis. CAP wird oft so zitiert, als müsste man sich dauerhaft zwischen Konsistenz und Verfügbarkeit entscheiden. Das stimmt nicht. Das Theorem greift im Fall einer Netzwerkpartition — also dann, wenn Teile des Systems sich nicht mehr erreichen. Im Normalbetrieb können Sie beides haben.

4:37 Und viele Systeme lassen die Konsistenz sogar je Anfrage einstellen. Der letzte Punkt macht daraus eine fachliche Frage, und so sollten Sie sie stellen: Was ist im Zweifel schlimmer — eine falsche Antwort oder gar keine? Bei einer Sitzplatzreservierung ist die Antwort eindeutig. Der Partitionsschlüssel ist eine dieser Entscheidungen, die klein aussehen und alles bestimmen.

5:00 Er legt fest, wie Ihre Daten verteilt werden, wo Hotspots entstehen und welche Abfragen überhaupt effizient möglich sind. Für Kartenwerk wäre die Veranstaltung ein naheliegender Schlüssel — mit dem unangenehmen Effekt, dass beim Vorverkaufsstart genau eine Partition die gesamte Last trägt. Und der letzte Punkt ist der, der weh tut: Ein schlecht gewählter Schlüssel lässt sich später kaum ändern, weil daran die gesamte Verteilung hängt.

5:24 Der erste Punkt ist die Folge des Missverständnisses von eben — CAP wird als Freibrief gelesen, überall auf Konsistenz zu verzichten. Der zweite ist der handwerkliche Klassiker: Der Partitionsschlüssel wird gewählt, bevor die Abfragen bekannt sind. Und der dritte beschreibt eine Sünde in die andere Richtung — die Normalisierung bleibt lehrbuchmäßig, und jede Anzeige braucht fünf Joins.

5:46 Datenmodellierung ist immer ein Kompromiss zwischen Schreib- und Leseseite, und den muss man bewusst schließen.

Daten in verteilten Anwendungen

5:53 Damit zu dem Teil, der wirklich schwierig wird. Sobald Daten mehreren Diensten gehören, brauchen Sie Muster für Dinge, die in einer einzelnen Datenbank die Transaktion erledigt hat. Der Satz über die gemeinsame Datenbank ist der wichtigste in diesem ganzen Modul. Eine geteilte Datenbank koppelt die Dienste über das Schema — und zwar so fest, dass sie weder unabhängig geändert noch unabhängig ausgeliefert werden können.

6:18 Sie haben dann alle Nachteile der Verteilung, weil die Aufrufe über das Netz laufen, und keinen einzigen Vorteil. In Modul acht bekommt das einen Namen: verteilter Monolith. Und diese Datenbank ist der häufigste Weg dorthin. Das Dual-Write-Problem klingt harmlos und ist eines der hartnäckigsten in verteilten Systemen. Ein Dienst muss die Datenbank ändern und eine Nachricht verschicken — und zwar beides oder keines.

6:42 Ohne Vorkehrung passiert genau das, was passieren muss: Irgendwann committet die Transaktion, und der Versand scheitert. Die Transactional Outbox löst das elegant: Die Nachricht wird in derselben lokalen Transaktion in eine Tabelle geschrieben. Ein eigener Prozess stellt sie danach zu — entweder durch regelmäßiges Abfragen oder durch Mitlesen des Transaktionslogs.

7:04 Diese vier Stationen erklären, warum die Outbox funktioniert. Der entscheidende Punkt liegt zwischen den ersten beiden Kästen: Transaktion und Outbox sind dasselbe atomare Ereignis. Entweder ist beides da oder nichts. Ab dem dritten Kasten gilt nur noch die Zusage „irgendwann" — der Relay kann verzögert sein, er kann eine Nachricht doppelt zustellen. Aber verlieren kann er nichts mehr.

7:27 Genau diese Verschiebung von „vielleicht" zu „später" ist der Gewinn. Lesen Sie diese Tabelle konsequent von rechts nach links — die Preisspalte ist die ehrlichere. Saga verzichtet auf Isolation, das I aus ACID, und verlangt Kompensation. Outbox kostet einen zusätzlichen Prozess und Verzögerung. CQRS bringt mehr Teile und verzögerte Sichten.

7:49 Und Event Sourcing erzwingt CQRS, weil sich ein Ereignisspeicher nicht wie eine Tabelle abfragen lässt. Die Fußzeile nennt noch die beiden Koordinationsformen der Saga: Choreographie über Ereignisse oder Orchestrierung über einen Koordinator. Event Sourcing ist faszinierend und wird aus den falschen Gründen gewählt. Die ersten beiden Punkte beschreiben das Prinzip: gespeichert wird die Folge der Ereignisse, der Zustand entsteht durch Abspielen. Die letzten beiden sind der Preis.

8:18 Der Ereignisspeicher lässt sich nicht abfragen wie eine Tabelle — schon eine einfache Übersicht braucht ein eigenes Lesemodell. Und die Programmierweise ist ungewohnt, für das ganze Team, über Monate. Wer nur einen Auditverlauf braucht, bekommt den deutlich günstiger. Der erste Punkt ist der, an dem Sagas in der Praxis scheitern.

8:38 Eine Kompensation ist nicht das Gegenteil der Aktion, sondern eine eigene fachliche Handlung — und manche lassen sich schlicht nicht rückgängig machen. Eine bereits eingelöste Eintrittskarte können Sie nicht zurücknehmen. Der zweite Punkt betrifft die Oberfläche: Wenn das Lesemodell hinterherhinkt und die Nutzerin nach dem Kauf ihre Buchung nicht sieht, ist das kein technisches Detail.

8:59 Das ist ein Supportfall.

Praxisübung

9:01 Zeit für die Anwendung. Kartenwerk hat drei Datenbestände, und die Frage nach ihrem Eigentümer ist die Entscheidung, die den Rest des Seminars trägt. Veranstaltungen und Kontingente, Buchungen mit Sitzplätzen, Zahlungen mit Belegen. Drei Bestände mit drei sehr verschiedenen Profilen: Der erste wird viel gelesen und selten geschrieben. Der zweite ist der Kern des Geschäfts und verträgt keine Fehler.

9:25 Der dritte hat regulatorische Anforderungen und Fremdsystembeteiligung. Wenn Sie für alle drei dieselbe Antwort geben, haben Sie die Unterschiede nicht genutzt — und zahlen für den einen Bestand mit, was nur der andere braucht. Der schwierigste Teil steht im Hinweis: das Kontingent beim Vorverkaufsstart. Dort treffen sich alle Themen dieses Moduls.

9:46 Zwanzigtausend Menschen greifen gleichzeitig auf denselben begrenzten Bestand zu, doppelt verkaufte Plätze sind teuer, und strenge Konsistenz kostet Durchsatz. Es gibt für diesen Fall keine elegante Lösung, sondern nur bewusste Kompromisse — etwa eine Warteschlange, die den Zugriff serialisiert. Genau darum geht es: nicht die richtige Antwort finden, sondern die eigene begründen können.

10:09 Der zweite Punkt ist der, den ich in echten Systemen am häufigsten sehe: Auf dem Papier gibt es einen Eigentümer, tatsächlich schreiben drei Dienste in dieselbe Tabelle. Datenhoheit, die nicht technisch durchgesetzt wird, ist eine Absichtserklärung. Und der letzte Punkt schlägt die Brücke zum vierten Modul: Verzögerte Sichten müssen in der Oberfläche vorbereitet sein.

10:30 Im nächsten Modul wechseln wir die Flughöhe und schauen auf den Zuschnitt des ganzen Systems.