Modular monolith boundaries
Extract a service only when its boundary is ready
A deployment split turns local dependencies into network and data contracts. Inspect those dependencies before moving a module into its own process.
In this article
Name the problem the split should solve
Independent scaling, release cadence or operational ownership can justify extraction. A desire to make the architecture diagram look more modern is not enough to explain the additional network, deployment and recovery work.
Measure the current constraint. If one module dominates CPU or requires a different release rhythm, that is useful evidence. If most changes still cross several modules, a service split may preserve the coupling while making it more expensive.
Keep the option of retaining the modular monolith. Extraction is a choice for a concrete need, not a required graduation step.
Inspect the data and transaction boundary
List direct reads and writes from outside the module. Replace unsupported mutations with a public contract before moving the process. Decide how reporting queries and read models will obtain data after the split.
Identify transactions that span the proposed boundary. A local database transaction cannot be preserved merely by replacing one method call with an HTTP request. The business invariant may need redesign, orchestration or a deliberate consistency tradeoff.
Document which service becomes the authoritative writer for each record. Shared unrestricted writes leave ownership ambiguous during and after migration.
Introduce the remote contract deliberately
Make timeouts, retries, idempotency and version compatibility explicit. Local calls may fail through exceptions, while remote calls can leave an uncertain result after the other service commits.
Use a controlled transition that routes a defined capability to the new service. Compare business results and observe latency and recovery behaviour. Avoid changing domain rules and deployment topology simultaneously unless the dependencies require it.
Keep source-of-truth and routing decisions clear during coexistence. Two active writers without a conflict rule create a migration problem that traffic percentages cannot solve.
Plan rollback around data ownership
A code rollback is insufficient if the new service has accepted writes the old application cannot see. Define how those records remain available and which writer is authoritative during restoration.
Test a change made after cutover, then rehearse rollback or the supported forward-recovery path. Include queued work and delayed responses.
Retire old access paths once the new boundary is proven. The extraction succeeds when it solves the original operating constraint and leaves explicit contracts for data, authority and recovery, rather than simply creating another deployable artifact.
Primary sources
Martin Fowler: Monolith FirstAWS Builders' Library: idempotent APIsReferences checked 11 September 2026.