The Dual-Write Dilemma
The proxy handles routing requests. The new service handles business logic. But there's a third challenge that is harder than both combined: data.
If you migrate the "UserProfile" functionality to a new service with its own modern database, the old monolith still needs that user data to function correctly for other features. The monolith's "Orders" module might join against the users table. The "Reporting" module might query user demographics. You cannot just shut off the old database.
You need the data to exist in both places simultaneously, and it must be kept in sync. This is the phase where most Strangler Fig migrations get stuck or fail.
There are three main strategies for handling this, each with distinct trade-offs:
- Shared Database (Transitional) — Both old and new systems read/write the same database. Simplest to implement, but creates tight coupling. Best used as a stepping stone.
- Dual Writes — The application writes to both databases simultaneously. Straightforward in concept, but introduces distributed consistency problems.
- Change Data Capture (CDC) — A tool watches the database transaction log and replicates changes asynchronously. Most robust, but requires additional infrastructure.
The right choice depends on your consistency requirements, team capabilities, and how entangled the data model is. We'll examine each in detail.