Why should you care?

Teams think they are doing microservices because they have two APIs. If both APIs hit Orders table directly, you still have one brain — just two mouths.

See it live — copy this example

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

// ❌ ANTI-PATTERN — Payment.Api writes Orders table
public async Task MarkPaid(Guid orderId)
{
    var order = await _sharedDb.Orders.FindAsync(orderId);
    order.Status = "Paid";  // Order team did not own this change!
    await _sharedDb.SaveChangesAsync();
}

// ✅ Order service owns order status — Payment publishes event
await _bus.Publish(new PaymentSucceededEvent(orderId, transactionId));

Run Example »

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

What happened?

• Payment tells the world payment succeeded.
• Order service listens and updates its own database.
• Payment never touches Order tables.

Try it yourself

1. List tables each service should own on paper.
2. If two services need the same table today, pick one owner.
3. Other service gets read-only API or event copy — not direct SQL.
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

Two services, one database = anti-pattern for independent deploy. Pick an owner for each table. Integrate with events or HTTP, not shared writes.

Real-world: Schema migration deadlock

Order team adds NOT NULL column; Payment nightly job breaks because it still inserts old shape. Shared DB means one team emergency on Friday night.

Outcome: Payment deploy never waits on Order migration window.