A modular monolith has clean, enforced module boundaries. What specifically makes extracting one of its modules into a standalone microservice straightforward, and what commonly makes it hard in practice even when the code-level boundary looks perfect?

## What extraction actually involves The promise of a modular monolith is that, because module boundaries are already enforced at the code level, extracting a module into its own deployable service later should be a mechanical, low-risk operation rather than a rewrite. Concretely, extraction means three things happen roughly in parallel for the module being pulled out: 1. Its public API interface gets a new implementation that makes an HTTP or gRPC call to the newly standalone service instead of an in-process method call. 2. Any domain events it published or consumed switch from an in-process publisher to a message broker so publishers and consumers can run in separate processes. 3. The module's own database tables move to a database the new service owns exclusively. If the module's boundary was genuinely respected the whole time — no other module ever imported its internal repository or entity classes, and no other module's queries ever joined against its tables — then callers in the remaining monolith don't need to change at all beyond the API implementation swap, because they were already coded against an interface and DTOs, not against the module's internals. ## The first obstacle: the database That 'if' is exactly where extraction usually gets hard in practice, and the gap between a clean code-level boundary and a clean extraction is the most important thing to understand about this path. **The single biggest risk is the database.** - Module-boundary tools check Java/Kotlin class dependencies; they have no visibility into SQL, so two modules can pass every boundary check while one module's query joins directly against another module's tables, or a foreign key constraint spans both modules' schemas. - None of that shows up until extraction time, when it turns into a hard requirement to either duplicate data with a synchronization mechanism to keep it eventually consistent, or rewrite the query as a cross-service call — both real engineering work, not a configuration change. Teams that anticipate extraction usually get ahead of this early by giving each module its own schema, even while still sharing one physical database instance, and treating cross-schema joins as a boundary violation on par with a cross-module import, which surfaces the coupling far earlier and far more cheaply than discovering it during the actual split. ## The second obstacle: transactions and latency The second common obstacle is transactional and latency behavior changing shape. Inside the monolith, a use case that touches two modules, say placing an order and reserving inventory, can often run inside one local, ACID database transaction, and a synchronous in-process call from `orders` to `inventory` costs microseconds. Once `inventory` is extracted, that same interaction becomes a network call with real latency, the possibility of partial failure where the network call times out after inventory was actually reserved, and no more shared transaction — correctness now requires either a distributed transaction pattern like a saga with compensating actions, or accepting eventual consistency and redesigning the use case around it. Code that was written against a synchronous API and never had to think about 'what if this call fails halfway' now has to. ## The third obstacle: operational readiness The third obstacle is organizational and operational, not code-level at all: does the team have, or need to build, service discovery, a per-service CI/CD pipeline, independent monitoring/alerting, and on-call practices for a new deployable? Extracting one module without that operational maturity often means the 'microservice' is deployed and monitored as an afterthought, a worse outcome than leaving it in the monolith. ## A pragmatic sequencing A pragmatic, commonly recommended sequencing is therefore: 1. **First**, make the module boundary real, with a public API and events verified in CI. 2. **Second**, give the module its own schema even before extraction, forcing all cross-module data access through the API/events and catching hidden database coupling early. 3. **Third**, watch the module's actual traffic and team ownership to see if it genuinely needs independent scaling or independent deployment cadence, since not every clean module needs to become a service, and modules with low traffic or that change in lockstep with the rest of the system are often better left inside the monolith indefinitely. 4. **Only then extract**, starting with the module that has the clearest, already-schema-isolated boundary and the strongest business case, such as needing to scale independently, or a separate team wanting an independent release cadence.