The Simplest Starting Point
Before jumping to complex synchronization, consider whether both the old and new systems can temporarily share the same database. The new "UserProfile" microservice connects to the same database the monolith uses, reading and writing to the same users table.
This violates the microservices principle of "each service owns its data," and that's okay — temporarily. The goal is to decouple the migration into smaller steps:
- First, extract the code (business logic) into a new service, keeping the shared database.
- Then, once the new service is stable and proven, extract the data into its own database using CDC.
This two-step approach reduces the number of things changing simultaneously. You're not migrating code AND data AND routing all at once. Reducing simultaneous change is the core discipline of safe migrations.
When this works:
- The legacy database schema is reasonably clean for the slice you're migrating
- Both systems use compatible database drivers
- You can tolerate the temporary coupling
- The migration timeline for data extraction is short and committed (weeks, not months)
When this breaks down:
- The legacy database uses stored procedures that embed business logic
- Schema changes in one system would break the other
- You need different database technologies (e.g., moving from Oracle to PostgreSQL)
- The "temporary" shared database becomes permanent because nobody prioritizes the data extraction step
Key Point: Purists will object to a shared database. Pragmatists will recognize it as a stepping stone. The Strangler Fig pattern is about incremental progress, not architectural perfection at every step. A shared database during migration is a conscious, temporary trade-off — document it explicitly with a clear timeline for when you'll complete the data extraction. Without that commitment in writing, "temporary" becomes "forever."