Modular monolith vs microservices

The deployable count is a decision that follows from where the boundaries sit, instead of one that precedes it. A module boundary and a service boundary are the same idea at different distances: one enforced by the compiler and the team's own discipline, the other enforced by a network and everyone who calls across it. Getting that boundary right is the actual design work, and it can be tested and corrected far more cheaply inside one process than it ever can once a network sits between the two sides.

Enforcement inside a monolith is a code-level constraint. A module that reaches into another module's tables, or imports a type it has no business depending on, shows up as an import that should not exist, a lint rule that fails, a code review comment noting that the logic belongs somewhere else. Fixing it is a rename and a move, tested by the same suite that already runs on every change, and reversible within the same afternoon if the new shape turns out to be wrong.

None of that holds once the boundary is a wire protocol. A module split into a service is depended on by clients that deploy on their own schedule, some of them still running last month's version of the contract. Moving a field, splitting a table, or discovering that two concerns once assumed separate in fact share a transaction now means a migration that has to preserve compatibility for everyone still on the old shape while the new one rolls out underneath them, rather than a local refactor tested by the same suite that already covers it.

Proving the boundary first, inside a single deployable, does the same work a split would eventually demand anyway, at a moment when a mistake still costs an afternoon instead of a cross-team migration. I would rather spend that afternoon undoing a wrong guess inside one process than discover the same mistake wearing a network protocol, coordinated across two teams and a deprecation window. A team that jumps straight to services because the boundaries feel obvious is betting that guess against a cost structure where the wrong guess grows more expensive in exact proportion to how confident everyone felt when they made it.

Each service earns its own deploy pipeline, its own versioning scheme, its own release calendar, because that independence is the entire point of splitting in the first place. What used to be one pipeline shipping the whole system together becomes as many pipelines as there are services, each with its own build, its own test suite, its own rollout strategy, and its own person who remembers what changed the last time it broke. The operational cost sits less in any single pipeline than in maintaining enough of them, well enough, over enough time, that none of them quietly rots into the pipeline nobody trusts to deploy cleanly.

A single request that used to live inside one process, visible in one stack trace, now crosses several services that each keep their own logs. Reconstructing what happened to a failed request means correlating a request id across every service it touched, in the right order, which is exactly what distributed tracing exists to automate. Without it, debugging a cross-service failure becomes an exercise in comparing timestamps across systems that were never designed to agree with each other precisely.

A schema or interface change can no longer assume every caller is ready for it, because callers now deploy on their own timeline rather than the one release that used to bundle everyone together. The realistic pattern is running two versions of a contract at once, deprecating the old one only once nothing still calls it, and treating consumer discovery, working out who still depends on the field being removed, as its own piece of work, not something a compiler catches for you across a network boundary.

A network call can fail in ways an in-process call never could: it can time out with the request half-processed on the other end, or arrive twice because a retry fired after the original response was simply delayed rather than lost. Handling that honestly means retries with backoff, timeouts set deliberately rather than left at whatever the client library defaults to, and circuit breakers that stop calling a dependency that is already struggling instead of adding load to it. When something does fail, the question I ask first is whether the fault started in the service that paged me or arrived from an upstream dependency that is failing too. On-call for one service now means understanding enough of the dependency graph around it to answer that, a wider brief than knowing the internals of the service the rota assigns.

A signal that justifies a split has to be true today, measured against the system as it currently runs, rather than a scaling story about where the product might be in a year. Three signals hold up under that test: a component whose load profile genuinely diverges from the rest, a component that needs to release on a different cadence than the rest, and a team boundary that already exists whether the architecture acknowledges it or not.

A scaling-profile signal is a component whose resource shape differs in kind, not just in volume, from the rest of the system: heavy compute against light memory, or a bursty workload sitting next to a steady one. Splitting it lets that component scale on its own signal instead of dragging the rest of the deployable along for a resource pattern the rest of the system does not share. A component that is merely busier than its neighbours, without a genuinely different shape, gets the same benefit from running more instances of the whole monolith.

A cadence signal is a component that wants to ship several times in the time the rest of the system ships once, typically because it sits closest to a fast-moving external dependency or a rapidly iterating part of the product. Bundled inside one deployable, its releases wait on the release train of everything else, and everything else inherits its risk on every deploy whether or not that deploy touched that code. Splitting it turns one shared release train into two trains running at the speed each genuinely needs.

A team boundary is the signal least visible on an architecture diagram and the hardest to argue against. Conway's law states plainly why: a system's structure ends up mirroring how the teams building it communicate, whether anyone designed it that way or not. Two teams who already own separate parts of the domain, who already coordinate through a defined interface rather than by sitting near each other, are describing a boundary that exists whether or not the code reflects it yet. Splitting along that line removes friction that was already there, while splitting along a line invented for the architecture, one no team boundary supports, creates friction that was not there before. I trust one strong signal on its own, a scaling profile that genuinely diverges, a cadence that genuinely needs independence, a team boundary that already exists, over three signals that are each present but weak, because a weak signal in every dimension usually means the boundary has not been tested hard enough yet to know where it truly sits.

The extraction that survives contact with production is the strangler pattern: put a seam in front of the module being extracted, route a slice of traffic through the new service while the old code path keeps running behind it, and grow that slice only as the new path proves itself against real load. Nothing about the interface facing the rest of the system needs to change during this, because the seam was already there before the extraction started. Only what answers on the other side of it changes.

That seam has to have already done real work as an interface inside the monolith, called across enough times, by enough different callers, that its shape has already survived contact with the rest of the system. Extracting a boundary that has never been exercised as an interface, one that was drawn on a diagram but never enforced in code, surfaces every hidden coupling it was quietly permitting at the worst possible time: during a live migration, in production, rather than during a code review where the fix costs nothing but an afternoon.

The database is the last thing to split, never the first, because splitting it commits the system to two sources of truth before anything has proven the split boundary is correct. Splitting the code first, and running it against a single shared database with each half accessing only the tables its own module already owned, tests the boundary under real traffic while a rollback still means reverting a deploy rather than reconciling data that has already diverged across two stores that both believe they are authoritative.

Picking which module to extract first is easiest when one of the earlier signals is already unambiguous: the module with the genuinely different scaling profile, or the one whose team already owns it as a separate unit in every way but the deployment boundary. I pick the clearest case over the most tempting one, so the team leaves the extraction with a working migration path, proven once under real conditions, that the next extraction can reuse instead of relearning under pressure.