Database-Per-Service Decoupling Checklist
A checklist for splitting a shared database into per-service ownership. It covers table ownership mapping, breaking cross-service joins, expand-and-contract schema splits, sagas, and reconciliation.
When to Use This Checklist
Use this checklist when separating a shared database into per-service ownership, a prerequisite for microservices that deploy and scale independently. The database-per-service pattern gives each service exclusive ownership of its data, accessed only through that service's API or events. A shared database is the most common hidden coupling that turns "microservices" back into a distributed monolith.
How to Use This Checklist
Begin with discovery: map every table to one owning service and find the cross-service joins and foreign keys that must be broken. Replace direct cross-schema reads with service calls or events. Decide how to handle data that previously relied on ACID joins across tables, usually through eventual consistency with events or sagas. Use the expand-and-contract pattern to split schemas without downtime, and reconcile data after migration.
Cut over per table behind a flag, keep dual-writes during stabilization, and monitor replication lag and consistency drift.
What Good Looks Like
A decoupled system gives each service sole write access to its tables, with no cross-schema joins remaining. Cross-boundary reads go through APIs or events, multi-table transactions are handled by sagas, and schema splits use expand-and-contract. Reconciliation confirms data consistency, dashboards track replication lag, and each split is reversible until proven stable.
Common Pitfalls
The defining failure is leaving a shared database in place, so services cannot truly deploy independently. Teams break foreign keys without replacing the consistency they provided. Splitting schemas in one big migration causes downtime; expand-and-contract avoids it. Skipping reconciliation lets silent data drift accumulate undetected.
Related Resources
See the database-per-service pattern, the saga pattern for cross-service transactions, and the expand-and-contract pattern for safe schema splits. Domain-driven design guides ownership boundaries and data quality management supports reconciliation.