Incremental extraction from the order monolith (2026 program)

The order-api monolith remains the system of record for order lifecycle, pricing hooks, and fulfillment handoff. Latency and release coordination have improved after modularization inside the repo, but deploys are still coupled: a change in promotions can block a hotfix in shipment tracking.

We have buy-in to extract read-heavy reporting and integration edges first, not to “microservice everything” in one pass. Data ownership is messy: several tables are written by batch jobs and online traffic; any cutover must define a single writer per aggregate to avoid split-brain writes.

Prior attempt (2024) stalled after a big-bang repo split with no strangler routing; this ADR encodes a different approach: thin edge services, shared database transitionally, then physical split when boundaries are proven.

We adopt an incremental strangler pattern. New external APIs for partners and internal clients will be served from dedicated services where those services own their read models; writes to core order state stay in the monolith until a follow-up ADR per bounded context authorizes moving the write path.

Each extraction ships with: (1) a defined API contract versioned in OpenAPI, (2) an explicit owner team in CODEOWNERS, (3) SLOs for availability separate from the monolith release train, and (4) a rollback path that does not require coordinated database migrations on the same day as code deploy.

Shared MySQL will remain the backing store for multiple services during transition; physical per-service databases are a phase-two goal after write ownership is enforced in application code and verified with integration tests.

Positive. Teams can ship integration endpoints without waiting for monolith release windows. Incident blast radius shrinks for read-only or async paths because failure domains are smaller and autoscaling can be applied per surface.

Negative. Operating two deployment models in parallel increases platform cost and requires careful logging correlation across services. Temporary shared tables mean strict reviews on new cross-table transactions; we will add linting for disallowed joins in new code outside the monolith.

Non-goals (explicit). Rewriting business rules in a new language, replacing the monolith ORM in one go, or mandating event sourcing. Those are out of scope for the 2026 program unless a separate ADR is accepted.

Follow-up. Architecture review will track extractions in a public migration board; any service that bypasses the OpenAPI gateway for North/South traffic must document a threat model update.