Monolith-to-Microservices Migration: Sequencing, Strangler Fig, Database Decomposition

Start with the anti-pattern warning

• Big-bang rewrites fail — every industry war story has the same shape
• Team promises 18 months, product keeps demanding features, parity never reached, cancelled at 24 months
• Strangler fig pattern from Martin Fowler is the proven alternative
• New growth wraps the old tree; old trunk shrinks and dies gradually
• There is never a weekend where everything changes

The sequencing playbook

• Step 1: stand up an API gateway in front of the monolith; every client talks to the gateway
• Step 2: pick first extraction carefully — not the most complex, not the most critical; something isolated like notifications or search
• Step 3: branch by abstraction inside monolith code — interface plus feature flag to switch between old impl and new microservice
• Step 4: dark-launch — both implementations run, results compared for weeks
• Step 5: canary traffic 1%, 10%, 50%, 100% over weeks; rollback on first SLO violation
• Step 6: retire old code only after weeks of zero traffic on the old path

Database decomposition is the hard part

• Services are easy; databases are hard
• Each future service must own its tables — draw boundaries with DDD
• Introduce schema-per-service in the same DB instance first; physical separation later
• Dual-write in application code is the #1 killer — distributed-transaction problem
• Better: Change Data Capture with Debezium; monolith writes only to its DB; CDC streams changes to Kafka; new service projects into its own schema
• Flip reads before writes; reads are safer to canary
• Hot cutover for writes — brief maintenance window on the endpoint, apply CDC tail, direct writes to new service
• Remove old tables only after snapshot and weeks of zero traffic

Extraction sequencing heuristics

• Lowest coupling first — natural seam exists
• Highest SLO-value outliers — a slow, unreliable piece is worth extracting
• Team autonomy unblockers — extract what's causing deploy conflicts
• Start with read-heavy extractions — search, recommendations, reporting
• Save hot-write tables for last — they typically span many domains

Realistic 12-month playbook

• Months 1–2: foundation — gateway, observability, Kafka, Debezium baseline
• Months 3–4: first extraction (notifications) — dark launch, canary
• Months 5–7: second extraction (search) — read-heavy, safer
• Months 8–10: first write extraction (orders) — CDC, read-flip, write hot cutover
• Months 11–12: cleanup, hardening, retrospective

When NOT to migrate

• Team under 15 engineers — modular monolith gives 80% of the value
• Engineering morale low, leadership wants a fresh start — rewrite by another name
• No on-call culture, no CI/CD maturity, no observability — prerequisites missing
• Team organized by layer, not by domain — Conway's law will poison the extraction

Common failure modes to name

• Distributed monolith — extracted services share one DB and call each other synchronously
• Premature extraction — service extracted before boundaries are clear; chatty integrations
• Dual-write failures — silent data drift between old and new
• Bidirectional dependencies — services pointing at each other create distributed deadlocks
• No protected migration capacity — feature pressure wins, migration stalls

Mid-migration health metrics

• Deploy independence — % of services deployable alone
• Shared DB count — should trend to zero
• Cross-service call depth per user request — target at most three
• Monolith LOC trend — should shrink month over month
• Shadow-traffic mismatch rate — target below 0.01%
• CDC lag p99 — target below 10 seconds

The strategic answer

• Never big-bang — always strangler fig
• Facade first to buy control; pick extractions carefully; dark launch and canary ruthlessly
• CDC for data decomposition, not dual-write
• Flip reads before writes; retire old code only after weeks of zero traffic
• Accept that 70% extracted may be the right terminal state — the long tail isn't always worth it
• Protect migration capacity at 30% minimum or it never happens