Why should you care?

Shared databases create hidden coupling — change a column and two teams break. Separate databases let each team evolve schema on their schedule.

See it live — copy this example

Create a Web API project (dotnet new webapi), paste the code, then run dotnet run.

// Order.Api/appsettings.json
{
  "ConnectionStrings": {
    "OrderDb": "Server=localhost;Database=ShopNest_Orders;Trusted_Connection=True;"
  }
}

// Program.cs
builder.Services.AddDbContext<OrderDbContext>(o =>
    o.UseSqlServer(builder.Configuration.GetConnectionString("OrderDb")));

Run Example »

Edit the code and click Run — like W3Schools Try it Yourself.

What happened?

• OrderDbContext maps to ShopNest_Orders database.
• Payment has its own connection string in Payment.Api — never copy Order connection into Payment.

Try it yourself

1. Install SQL Server Express or use LocalDB on Windows.
2. Add EF Core packages to Order.Api.
3. Create OrderDbContext with Orders table.
4. Change a string or route in the example and save — watch Swagger or the RabbitMQ Management UI update.
5. Break the code on purpose (remove a semicolon), read the error message, then fix it.

Remember

One service → one database (logical ownership). No cross-service foreign keys. Duplicate read data when needed — consistency via events later.

Real-world: Payment PCI scope

Card tokens live only in PaymentDb. OrderDb stores paymentId reference — not PAN numbers.

Outcome: Security audits draw a circle around PaymentDb only.