Database Per Service

1. What exactly is Database Per Service?

A Billing service and a Shipping service both read and write the same Orders table, in one Azure SQL Database.

Now the Billing team adds a new column and changes how they update a status field on that table. The Shipping service was relying on the old row structure, and it quietly starts showing customers the wrong delivery status.

A change one team makes to its own table quietly breaks a service that team has never even talked to. That's exactly what database-per-service prevents.

2. How would you fix it in .NET/Azure?

Database-per-service draws a hard line around each service's data: give each one its own Azure SQL Database, or its own Azure Cosmos DB container, holding only the data that service owns. When another service needs that data, it calls the owning service's API instead of reading its database directly, so the owning service can change its own table's structure freely.

Use: Azure SQL Database, Azure Key Vault

Own your data, and let everyone else ask you for it instead of reaching past you to get it.

3. How can you visualize it in everyday terms?

A basement storage room shared by every tenant in a building gets reorganized by whoever needs space that week, and everyone else's boxes end up moved or buried.

Give each tenant their own storage unit instead, and they can rearrange it however they like. Nobody else's boxes are ever affected.

Free to rearrange your own unit, without ever moving anyone else's boxes.