monolith-to-services-extraction

Monolith → Services Extraction

"Rewrite as services" never works. "Extract one service incrementally over 3-6 months" sometimes does. This skill walks the strangler fig pattern that keeps the monolith working while the new service grows.

The opinion

Use the strangler fig pattern. Do schema-level decoupling FIRST (separate tables / DB). Dark-launch the new service (production traffic, results discarded). Then dual-write (both systems write, old is source of truth). Then dual-read (both serve, compare). Finally, cut over. Keep the rollback path open until you've gone a full month without rolling back.

The whole point: at no time should production be broken. Every step is reversible until the very last cleanup.

The 7-stage strangler fig

1. Identify the seam
2. Decouple at the schema layer (in the monolith)
3. Stand up the new service (parallel infrastructure)
4. Dark-launch (shadow traffic)
5. Dual-write
6. Dual-read with diff
7. Cut over
8. Cleanup (remove old code)

You can spend weeks on each. That's fine.

Stage 1: Identify the seam

The seam is the place where the monolith TALKS to the future-service.

# Current monolith
class OrderController < ApplicationController
  def create
    order = Order.new(order_params)
    InventoryReserver.new(order).reserve!     # ← this will become a service call
    order.save!
    BillingProcessor.new(order).charge!       # ← this too
    render json: order
  end
end

You're going to extract Inventory and Billing. The seams are InventoryReserver and BillingProcessor. Make sure they have well-defined interfaces (a call method, an explicit success/failure result) before going further.

Stage 2: Schema-level decoupling

Before code is in two places, the DATA must be cleanly owned by one place.

# Before — inventory data scattered:
class Product < ApplicationRecord
  has_one :stock_level
end

class Order < ApplicationRecord
  has_many :inventory_reservations  # in same DB, with FKs
end