Read-First Extraction

When strangling a monolith, the tempting first extraction is the interesting logic — which is almost always on the write path. That choice forecloses the cheapest available reversal.

Reads are reversible. Build the new service, populate its store by change data capture, serve reads from it behind a flag, and if it is wrong, flip the flag. No data was lost and no state diverged.

Writes are not. A write migration that turns out to be wrong leaves records in two places with a discrepancy that must be reconciled.

Why it matters

It converts the risky part of a migration into a series of cheap experiments. The read extraction also establishes the new service's data model, its operational characteristics and its correctness under production load — all of which are prerequisites for the write migration anyway.

Implementation patterns

• A façade in front of all traffic first, so subsequent steps need no client change. Clients are the slowest thing to move and they should be moved once.
• Populate the new store from the monolith by change data capture, so the old system remains authoritative and the new one is explicitly a projection. Two authorities for one fact produces permanent reconciliation work.
• Shadow before serving: send production reads to both and compare. This finds the semantic divergences no amount of code review will, at low cost and with no customer exposure.
• Serve behind a flag with per-entity or per-segment granularity, so rollout is progressive and rollback is immediate.
• Only then dual-write, verify, and cut over, with the monolith's table becoming read-only.
• Remove the old code path, with a date and an owner. This is the step that is skipped, leaving the estate carrying both permanently.

Industry example

Payment and wallet platforms such as MobiKwik cannot pause to migrate, and their correctness requirements make an unnoticed divergence expensive. The read-first order is what lets them establish confidence in a new service under real load before anything irreversible happens.

The one qualification for a ledger: balances cannot be temporarily wrong, so the dual-write comparison must be a full reconciliation rather than a sample — a sample match implies an unknown discrepancy everywhere else.

Failure scenarios

• Writes extracted first, forfeiting cheap reversal.
• No shadow comparison, so semantic divergences are found by customers.
• Both systems authoritative during the transition, producing reconciliation work that outlives the migration.
• The façade left in place permanently, adding a hop with no owner.
• The old path never removed, so the migration's cost is paid and its benefit is not.

Trade-offs

Read-first is slower to deliver visible progress: the interesting logic is still in the monolith after the first phase, and stakeholders may perceive the migration as stalled.

It also requires building the change-capture pipeline before any benefit is realised, which is real infrastructure work with no immediate payoff. That cost buys reversibility on every subsequent step, which is the entire argument — and it is worth stating explicitly to whoever is impatient about the sequencing.

Interview question

"You are extracting the order service from a monolith. Take me through your first three deployments and tell me, at each one, exactly how you would roll back."