Integration Risk in an Incremental Migration
A logistics firm is migrating a monolithic order system to services over 24 months. The monolith handles 4,000 orders/hour at peak and shares a single database with a legacy billing system maintained by a different vendor. The team plans to extract the order-capture service first because it is 'cleanest.' During integration planning, they discover the monolith writes to the billing tables through triggers that no one documented. The vendor contract requires 99.9% billing availability and prohibits schema changes without 90 days' notice. The program manager wants to proceed with extraction and 'fix integration later.'
1. Assess the proposed extraction-first plan and identify the integration risks that make it unsafe.
Read the worked answer
The plan is unsafe because the extraction boundary was chosen by code cleanliness, not by coupling and dependency analysis. Key risks:
- Hidden coupling: undocumented triggers mean order-capture is not actually separable; extracting it can break billing writes silently.
- Contractual constraint: the 90-day schema-notice clause turns any integration change into a schedule event; 'fix later' may collide with the clause.
- Availability target: a 99.9% billing SLA means integration failures are contract breaches, not just defects.
- Shared database: two systems writing one schema creates a distributed-consistency problem the plan does not address.
The answer should conclude that integration risk must be assessed before boundary selection, and recommend a discovery step (trigger/data-flow inventory) before committing to extraction order.
2. Recommend a sequencing and integration approach that respects the constraints.
Read the worked answer
A defensible recommendation:
- Discovery first: inventory triggers, data flows, and vendor-owned schema dependencies; produce an integration map.
- Resequence: likely extract a component with a clean, non-shared boundary first, or introduce an anti-corruption layer between monolith and billing to isolate the shared schema.
- Integration pattern: use an intermediary (message/queue or facade) so order-capture does not write billing tables directly; this reduces the chance of needing schema changes inside the 90-day window.
- Contract alignment: plan any schema change against the 90-day notice, treating it as a milestone.
- Verification: define integration tests and availability monitoring against the 99.9% target before cutover.
The answer must connect each step to a named constraint (triggers, SLA, notice period).
3. The program manager says integration can be fixed after extraction. Explain why this reasoning fails and what evidence would change the decision.
Read the worked answer
The reasoning treats integration as a downstream defect-fixing activity rather than an architectural property determined at boundary selection. Once order-capture is extracted against a shared schema with undocumented triggers, 'fixing' integration means either changing the vendor schema (blocked by 90-day notice) or building compensating logic under schedule pressure, both of which endanger the SLA.
Evidence that would legitimately change the decision:
- A verified trigger/data-flow inventory showing no order-capture dependency on billing writes.
- A vendor agreement permitting the needed schema change within the timeline.
- A proven anti-corruption layer with integration tests demonstrating 99.9% availability under peak load.
Without such evidence, deferring integration work shifts risk to the highest-cost phase. The answer should distinguish 'we can fix it' from 'we have evidence we can fix it within constraints.'