Der Dienst Ausschreibungen läuft seit Lektion 4.12.1 für sich, aber er schreibt noch in die gemeinsame Datenbank der Kladde. Seine Tabellen liegen seit Lektion 4.3.6 im Schema tenders, und nur er fasst sie an. Das ist schon viel, aber nicht genug: Ein neues Feld, ein Index, eine Sicherung, ein Ausfall der Datenbank, all das betrifft weiter beide. Diese Lektion zieht die Daten um, ohne dass eine Person es merkt, und klärt, was danach nicht mehr geht.

Wem die Datenbank gehört

Die Regel aus Microsofts Leitfaden „Data considerations for microservices“ ist kurz: Zwei Dienste teilen sich keinen Datenspeicher. Jeder Dienst verwaltet seine Daten privat, und andere greifen nicht direkt darauf zu. Der Grund ist Kopplung: Lesen zwei Dienste dieselbe Tabelle, muss jede Änderung ihres Schemas zwischen beiden abgestimmt werden, und keiner kann mehr allein ausliefern. Die vierte Prüffrage aus Lektion 4.12.1 wäre verletzt.

Der Leitfaden sagt auch, was erlaubt ist: Dienste dürfen sich denselben physischen Datenbankserver teilen. Das Problem ist nie der Server, sondern dasselbe Schema oder dieselben Tabellen. Daraus ergeben sich drei Stufen der Trennung:

Stufe Wie Was getrennt ist Was geteilt bleibt
eigenes Schema tenders.* in der gemeinsamen Datenbank, ein Datenbankbenutzer je Dienst mit Rechten nur auf sein Schema (Lektion 4.8.5) Tabellen und Rechte Sicherung, Wiederherstellung, Leistung, Ausfall, Ausrollen von Schemaänderungen
eigene Datenbank tendersdb auf demselben Server zusätzlich Sicherung und Wiederherstellung je Dienst, eigene Größe und Leistungsstufe in Azure SQL der Server, seine Anmeldung und seine Netzregeln
eigener Speicher ein eigener Server oder eine andere Technik, etwa Cosmos DB alles nichts

Der Leitfaden nennt die letzte Stufe polyglot persistence: Jeder Dienst wählt den Speicher, der zu seinen Daten passt. Für die Kladde ist die zweite Stufe richtig. Die Ausschreibungen sind relational, eine zweite Technik brächte nur Betrieb, und eine eigene Datenbank auf dem vorhandenen Server trennt das, was zählt: Schema, Rechte, Sicherung, Leistung.