Since lesson 4.12.1 the tenders service has been running on its own, but it still writes to the Kladde's shared database. Its tables have lived
in the schema tenders since lesson 4.3.6, and only the service touches them. That is a lot, but not enough: a new column, an index, a backup,
an outage of the database, all of it still affects both. This lesson moves the data without anyone noticing and clarifies what no longer works
afterwards.
Who owns the database
The rule from Microsoft's guide “Data considerations for microservices” is short: Two services don't share a data store. Each service manages its data privately, and others don't access it directly. The reason is coupling: If two services read the same table, every change to its schema has to be agreed between both, and neither can deliver alone any more. The fourth check question from lesson 4.12.1 would be violated.
The guide also says what is allowed: Services may share the same physical database server. The problem is never the server, but the same schema or the same tables. That gives three levels of separation:
| Level | How | What is separate | What stays shared |
|---|---|---|---|
| own schema | tenders.* in the shared database, one database user per service with rights only on its schema (lesson 4.8.5) |
tables and rights | backup, restore, performance, outage, rolling out schema changes |
| own database | tendersdb on the same server |
in addition backup and restore per service, own size and performance tier in Azure SQL | the server, its sign-in and its network rules |
| own store | a server of its own or another technology, such as Cosmos DB | everything | nothing |
The guide calls the last level polyglot persistence: Each service chooses the store that suits its data. For the Kladde the second level is right. The tenders are relational, a second technology would only bring operations work, and a database of its own on the existing server separates what counts: schema, rights, backup, performance.