Incremental extraction from the order monolith (2026 program)
- Status: proposed
- Deciders: <team or role>
- Technical story: <issue link> · Date: <YYYY-MM-DD>
Context and Problem Statement
A live monolith still holds core state but deployments and data ownership are tangled. Prior big-bang extraction failed. We need a strangler with explicit write ownership, incremental cutovers, and honest non-goals.
Decision Drivers
- Smaller release blast radius for integrations
- Clear ownership and contracts per extracted surface
- No pretend microservices without data discipline
Considered Options
- Strangler with shared DB (then split) — match current skills; transitional complexity
- One-shot split — rejected after 2024 failure and operational risk
Decision Outcome
Strangler: read path extraction first, OpenAPI+SLO+owner per service, monolith write path until a focused ADR moves it. Shared DB is explicit short-term; physical per-service DB is later.
Consequences
- Read surfaces can scale independently; operational load rises until write paths converge
- Linting and design review guard shared-table access from new code
Pros and Cons of the Options (summary)
Strangler matches team capacity; tradeoff is temporary operational complexity and careful correlation in incidents.
Confirmation
Architecture review + product Eng leads; migration board is the public tracker.