You need to migrate user data from a monolithic database to a new microservice without downtime. How would you plan and execute this migration?
How I frame it
Zero downtime means users never see maintenance window. Use strangler fig + dual-write / dual-read with reconciliation — not big-bang cutover.
Phased plan
- Replicate: CDC (Debezium) or batch ETL monolith → user service DB. Monolith still writes.
- Dual write: Monolith writes users to both DBs (sync or async). Reconciliation job diffs counts/hashes nightly.
- Shadow read: User service reads own DB for validation; compare responses to monolith in shadow mode (log mismatches).
- Cutover reads: Feature flag routes GET /users to new service.
- Cutover writes: New service owns writes; monolith becomes read-only proxy or stops user writes.
- Decommission: Stop dual-write after 0 drift for N days; archive monolith user tables.
Non-negotiables
- Backward-compatible API — old mobile apps still work during migration.
- Idempotent sync — replay safe.
- Rollback flag — flip reads/writes back to monolith if error budget burns.
Walkthrough
Week 1: CDC streams users to User Service DB; monolith still sole writer. Week 3: dual-write on profile update — nightly job finds 12 drift rows, auto-repair. Week 5: 10% read traffic to new service via flag; mismatch rate 0.01% — fix mapping bug. Week 7: 100% reads + writes on new service; monolith user table read-only. Week 9: decommission after 14 days zero drift.
Weak answer
"Stop traffic, mysqldump, restore, resume." Maintenance window, not zero downtime. "Big-bang cutover Saturday night" — one bug rolls back entire launch; no gradual validation.
Follow-up questions
Foreign keys from orders to users during migration?
Stable user_id UUID across both systems; never renumber. Orders keep FK to same id.
PII / GDPR delete during dual-write?
Delete propagates to both stores in one orchestrated command; tombstone in event bus.