A billing platform is extracting services from a shared database. Should the code be split first or the data?
Show the full answer Hide the answer
The order that works
Ownership, then code, then data — and the first step is the one that is skipped because it sounds like process rather than architecture.
- Assign ownership of each table to one team, with schema changes requiring their approval. Costs nothing, stops the worst of the coupling immediately, and makes every subsequent step tractable.
- Give other teams a read contract — an API, a replica, or a change-data-capture projection they own. Reads are usually the majority of the access and the easy half.
- Move writes behind the owner's interface. The expensive step, and the one that actually removes the coupling.
- Split the physical database, last and only if needed. Separate schemas or separate databases are an operational decision that follows the logical separation rather than preceding it.
Why splitting the data first fails
It converts a local join into a distributed one and a local transaction into a saga, before anyone has established whether those boundaries are right. If the boundary turns out to be wrong — which is common on a first attempt — moving it back is far harder than moving a code boundary.
Why splitting the code first also fails
Services split while sharing a database have all the deployment complexity of microservices and none of the independence: the schema is still a shared coupling point, migrations are still cross-team events, and lock contention still crosses service boundaries. This is the most common intermediate state and it is worse than either endpoint.
The billing-specific consideration
Invoice generation and proration share money invariants and belong in one transactional boundary. A decomposition that separates them converts a local calculation into a distributed consistency problem for no benefit.
Tax, dunning, accounting sync and document rendering are the natural extractions, because they change for different reasons, at different cadences, driven by different stakeholders — and because none of them enforces a money invariant that the core needs.
The boundary announces itself through change history: what has been deployed together, and what has ever broken together. That evidence is available in ten minutes and is more reliable than any modelling exercise.