Datenarchitektur

Willkommen zu Kapitel 7: Datenarchitektur. Code lässt sich in Monaten neu schreiben, Daten aber leben Jahrzehnte. Kundenkonten, Hauptbücher, Bestellungen und Krankengeschichten überdauern jedes Framework und jeden Service, der mit ihnen arbeitet. Diese Daten zu migrieren ist langsam, riskant und teuer. Deshalb gehören die Entscheidungen in diesem Kapitel zu den bedeutsamsten, die ein Architekt trifft: Sie sind schwer rückgängig zu machen, weitreichend und entscheidend für Verfügbarkeit, Performance und Änderbarkeit.

Dieses Kapitel richtet sich an Entwicklungs- und Architekturfachleute, die die verteilten Stile aus Kapitel 6 schon kennen und nun fundierte, begründbare Entscheidungen über Daten treffen müssen. Es baut direkt auf Kapitel 6 auf. Code in Services aufzuteilen ist die leichte Hälfte. Sobald es mehrere Services gibt, muss jemand entscheiden, wer welche Daten ändern darf, wie andere sie sehen und was geschieht, wenn Kopien voneinander abweichen. Es setzt außerdem die Datenbankgrundlagen aus dem Abschnitt über das Speichern von Daten in Kapitel 0 voraus. Wenn Tabellen, Abfragen und Transaktionen neu für Sie sind, beginnen Sie dort. Und es führt weiter zu Kapitel 8, das diese Daten und das System als Ganzes schützt.

Das Kapitel hat acht Abschnitte und folgt durchgehend zwei Beispielen: einer Essenslieferplattform mit abendlichem Ansturm, Kurierstandorten und Speisekarten und einer Onlinebank, bei der es inakzeptabel ist, eine einzige Zahlung zu verlieren oder doppelt zu zählen. Abschnitt sieben Punkt eins, über Datenhoheit, legt die wichtigste Regel fest: Jede wichtige Tatsache sollte genau ein System of Record und genau einen Schreiber haben. Er erklärt, warum eine gemeinsame Datenbank Services koppelt, wie sauber ihr Code auch getrennt sein mag. Abschnitt sieben Punkt zwei gibt einen Überblick über relationale, Dokument-, Key-Value-, Graph-, Zeitreihen- und andere Speicher. Er begründet, warum die relationale Datenbank der richtige Standard für Systems of Record bleibt und jeder spezialisierte Speicher sich seinen Platz verdienen muss. Abschnitt sieben Punkt drei blickt unter das vertraute Akronym ACID auf die Anomalien durch Nebenläufigkeit, etwa Lost Updates und Write Skew, und darauf, was Isolationsebenen in verbreiteten Datenbanken wirklich garantieren. Abschnitt sieben Punkt vier erklärt, wie Datenbanken Daten über Maschinen kopieren und aufteilen, was Replikationsverzögerung und Failover mit der Korrektheit machen und wie man einen Shard-Schlüssel anhand der Zahlen wählt.

Hier ist der erste und wichtigste Gedanke des Kapitels, aus Abschnitt sieben Punkt eins. Das Bild vergleicht zwei Wege, drei Services ihre Daten zu geben. Links lesen und schreiben die Services für Bestellungen, Küche und Lieferung alle eine gemeinsame Datenbank mit Bestellungen, Speisekarten und Kurieren. Jeder Service kann jede Tabelle ändern, also ist jede Tabelle eine öffentliche Schnittstelle, und jede Schemaänderung braucht ein koordiniertes Release. Rechts hat jeder Service seine eigene Datenbank. Jedes Schema ist privat, es gibt keine Joins über Datenbanken hinweg, und Daten überqueren die Grenzen nur über API-Aufrufe und Events. Jetzt kann jeder Eigentümer sein Schema allein ändern. Diese Unabhängigkeit hat ihren Preis. Joins, Transaktionen und referenzielle Integrität über Services hinweg müssen durch APIs, Events, Sagas und Reporting-Pipelines ersetzt werden, und der Abschnitt zeigt, wie man Daten liest, die einem nicht gehören.

Die zweite Hälfte des Kapitels behandelt Daten, die aus den Systems of Record abgeleitet werden, und Veränderung über die Zeit. Abschnitt sieben Punkt fünf behandelt Command Query Responsibility Segregation, kurz CQRS, und Event-Sourcing. Sie trennen das Modell, das Änderungen annimmt, von den Modellen, die Abfragen beantworten, und speichern eine Ereignishistorie statt des aktuellen Zustands, zu einem echten Preis an Komplexität. Abschnitt sieben Punkt sechs handelt vom Caching: Kopien nahe am Ort ihres Bedarfs vorzuhalten, vom Browser bis zur Datenbank, einschließlich der Stampedes, die ein System lahmlegen können, wenn ein beliebter Eintrag abläuft. Abschnitt sieben Punkt sieben geht davon aus, dass sich jedes Schema, ob Datenbanktabellen, API-Payloads oder Events, im laufenden Betrieb ändern wird. Kompatibilitätsregeln und das Expand-and-Contract-Muster ermöglichen diese Änderung ohne Ausfallzeit. Zum Schluss geht Abschnitt sieben Punkt acht vom Betreiben des Geschäfts zu seinem Verstehen über: Data Warehouses, Data Lakes und Lakehouses, Stream Processing und Data Mesh, ein Weg, analytische Daten entlang von Domänen zu organisieren.

Die Abschnitte bilden eine Kette, und dieses Diagramm aus Abschnitt sieben Punkt zwei zeigt diese Kette an einer Essenslieferplattform. Bestellungen und Speisekarten schreiben jeweils in ihre eigene PostgreSQL-Datenbank. Das sind die einzigen beiden Systems of Record, und sie halten Bestellungen, Zahlungen und Speisekarten. Alles andere ist eine bewusste Kopie. Kurierpositionen liegen in einem In-Memory-Key-Value-Store und laufen nach dreißig Sekunden ab. Change Data Capture kopiert Speisekartenänderungen mit wenigen Sekunden Verzögerung in eine Suchmaschine. Und ein Data Warehouse erhält Bestellungen, Speisekarten und Stichproben von Kurierpositionen für Analytics, Stunden alt. Jede Kopie ist für einen Zweck schneller oder bequemer, jede ist um ein gewisses Maß veraltet, und jede lässt sich neu aufbauen.

Diese Kette führt zu dem einen Gedanken, den Sie aus diesem Kapitel mitnehmen sollten. Für jedes wichtige Datum sollten Sie drei Fragen beantworten können. Erstens: Wer ist sein einziger Schreiber? Zweitens: Wo werden seine Regeln durchgesetzt? Und drittens: Wie veraltet darf jede Kopie davon sein? Die meisten Datenprobleme in realen Systemen, etwa Bestellungen, deren Status rückwärts springt, Berichte, die dem Hauptbuch widersprechen, Doppelbuchungen und Kunden, die ihre eigenen Änderungen nicht sehen, entstehen, weil eine dieser Fragen nicht bewusst beantwortet wurde. Die Techniken in diesem Kapitel sind Wege, sie gut zu beantworten, und jede ist eine Abwägung zwischen Konsistenz, Verfügbarkeit, Performance, Kosten und dem Aufwand für den Betrieb des Systems.

Am Ende des Kapitels können Sie die Hoheit über Daten zuweisen, auch in den heiklen Fällen, in denen mehrere Services dieselben Daten schreiben wollen. Sie können für jeden Datenbestand eine Datenbank nach Form, Zugriffsmustern, Konsistenzbedarf und Größenordnung wählen und die Kosten jedes zusätzlichen Speichers begründen. Sie wissen, wie man einen Lese-, Änderungs- und Schreibpfad mit Sperren, Versionsprüfungen oder serialisierbaren Transaktionen absichert. Und Sie können Schemaänderungen mit Kompatibilitätsregeln und Expand and Contract so planen, dass sie keine Ausfallzeit brauchen.

Weil die Abschnitte eine Kette bilden, lesen Sie sie am besten der Reihe nach. Jeder steht aber auch für sich, sodass Sie direkt zu dem Abschnitt springen können, den Sie brauchen. Planen Sie für das ganze Kapitel etwa dreieinhalb Stunden Lesezeit ein. Jeder Abschnitt endet mit Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen; so sehen Sie schnell, was hängen geblieben ist. Wenn Sie so weit sind, gibt es einen freiwilligen Kapiteltest, der etwa fünfundvierzig Minuten dauert. Er hat zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten. Die Bestehensgrenze liegt bei achtzig Prozent.

So ist das Kapitel aufgebaut. Beginnen Sie mit Abschnitt sieben Punkt eins über Datenhoheit und Datenbank pro Service, wo die Regel „ein Schreiber für jede Tatsache“ ausführlich dargelegt wird. Bis gleich.