Why should you care?

When Order and Payment share one database, a bad migration on Payment can break checkout. Separate data stores let teams evolve schema independently.

See it live — copy this example

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

// Order.Api  → ShopNest_Orders (SQL Server)
// Payment.Api → ShopNest_Payments (SQL Server)
// Catalog.Api → ShopNest_Products (PostgreSQL + read replica)

// Order stores customerId (Guid) — not User.Email column from another DB

Run Example »

This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.

What happened?

• Database-per-service is the default.
• Use events or APIs to sync read models — not cross-database joins.
• Eventual consistency is normal.

Try it yourself

1. List ShopNest services and assign one database name each.
2. Draw which fields are copied vs fetched via API (e.g. order line stores price snapshot).
3. Document one anti-pattern you will avoid (shared Users 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 ownership. Sync via events or API — not shared tables. Pick SQL vs NoSQL per service needs.