When extracting a service from a monolith that shares one relational database, what are the main strategies for giving that service its own data, and what makes this the hardest part of a strangler-fig migration?

## Why this is the hardest step Splitting a shared relational database is widely regarded as the hardest part of a strangler-fig migration, harder than the routing and code-extraction work, because: - data — unlike code — must remain correct and consistent under concurrent access from both the old and new systems throughout the transition; - a completed data split is much harder to reverse than a routing change. Before any split, a monolith and its new service typically share one schema; the new service's tables are entangled with everyone else's via foreign keys, joins, and transactions that the relational database enforces "for free." None of that comes for free anymore once ownership is split across two independently deployed systems with two separate databases. ## Establishing table ownership The first step is establishing clear **table ownership**: for each table, decide which service is now the single owner responsible for writing to it, following the bounded-context lines identified during seam analysis. Tables owned by the newly extracted service are physically moved into a schema (or a wholly separate database instance) that only that service can write to; any other service that needs that data must now go through the owning service's API rather than querying its tables directly — a discipline that's easy to state but requires real vigilance to enforce, since a straight-line query is always tempting during the transition. ## Keeping two stores consistent The central technical challenge is keeping the old and new stores consistent while both are live. Two main approaches exist. | Approach | How it works | How it behaves under failure | |---|---|---| | **Application-level dual writes** | have the application code explicitly write to both the monolith's original tables and the new service on every relevant operation | this is simple to reason about but fragile, because the two writes aren't atomic — if the application crashes or the network fails between the first write succeeding and the second completing, the two stores silently diverge with no automatic recovery | | **Change-data-capture (CDC)**, using a tool such as Debezium that reads a database's write-ahead log or binlog | instead streams every already-committed change as an event without any dual-write code in the application at all | because it reads from the single authoritative source of truth after commit, there's no window where a crash can leave the two stores in different states relative to what the application intended — it can at worst lag, not diverge | For this reason CDC is generally preferred over hand-rolled dual writes wherever it's available, though it adds its own operational component (a CDC pipeline) that must be run and monitored. ## When one transaction becomes a saga A second major challenge is what happens to operations that used to be a single **ACID transaction** spanning tables that are now owned by different services — for example, canceling an order and issuing a refund, which the monolith could do atomically in one commit. Once orders and payments are separate services with separate databases, that atomicity is no longer available; distributed two-phase-commit transactions across services are technically possible but rarely used in practice because they couple services tightly and reduce availability (all participants must be up and responsive). The standard replacement is a **saga**: a sequence of local transactions in each service, with an explicit compensating action defined for each step so the overall operation can recover from partial failure without a distributed lock. This trades strong, immediate consistency for eventual consistency, meaning the system genuinely can be observed in an intermediate state — the design has to account for and expose that rather than pretend it can't happen. ## Failure modes The database-split step's failure modes are more consequential in production than most other migration steps because they involve real user data. - **Dual writes that lack reconciliation.** Application-level dual writes that lack any reconciliation job routinely produce silent divergence that isn't discovered until a customer notices a missing order or a wrong balance, sometimes weeks later. - **Distributed transactions under load.** Attempting a distributed transaction across newly split services under load tends to surface as cascading timeouts and reduced availability, since the transaction can only complete as fast as its slowest participant and blocks resources on all of them meanwhile. - **Rollback after both systems have accepted writes.** And unlike a routing flag that can be flipped back instantly if a code-level extraction goes wrong, once two systems have independently accepted writes to the same logical record for any period of time, reconciling those writes on rollback may involve genuine, unrecoverable conflicts — which is why teams invest heavily in comparison/verification tooling before finalizing a split, treating it as the point of no return in the migration.