I want to tell this story in the order it actually happened, mistakes included, because the sanitized version where we nailed the architecture on the first try would be a lie and wouldn't teach anyone anything useful.

Attempt one: splitting too early

A client came to us with a working monolith, maybe 18 months of traction, and a founding team that had just read a few conference talks about microservices at companies with a thousand engineers. They wanted to split it up before we'd even finished the audit. We should have pushed back harder than we did. We split the app into six services — users, billing, notifications, catalog, orders, and search — because that's roughly how the codebase's modules were already organized. Six months later, the team of five engineers was spending more time debugging distributed tracing across service boundaries than shipping features. A feature that used to be a single database transaction across three tables was now three services, two of which had to communicate over HTTP, with all the retry logic, timeout handling, and partial-failure states that implies for what used to be one atomic operation.

The tell that we'd gotten it wrong: nobody could deploy a single service in isolation because they were all still tightly coupled through shared business logic, just now separated by a network boundary instead of a function call. We'd paid the full complexity cost of microservices — network latency, partial failure, distributed debugging, service discovery — without getting the actual benefit, which is independent deployability and independent scaling.

Attempt two: merging back, overcorrecting

So we merged it back into a monolith. This was the right call, but we overcorrected in how we did it — we collapsed everything into one Express app with no internal module boundaries at all, and eighteen months later that monolith had the exact tangled-dependency problem monoliths are famous for. Any change to the billing module risked breaking notifications because someone, at some point, had imported a billing utility function directly into the notification code because it was three lines away and reusing it seemed harmless at the time. That kind of shortcut compounds. We'd fixed the deployment complexity problem and reintroduced the coupling problem, just inside one process instead of across a network.

Attempt three: the boring, correct answer

What actually worked, on the third try with a different client where we got to set the direction from day one, was treating microservices as an answer to a specific organizational and scaling problem, not a default architecture. We kept a well-organized monolith — real module boundaries enforced by internal package structure, not just folder names, with explicit interfaces between modules — for as long as the team was small enough that cross-team coordination wasn't the bottleneck.

The actual trigger for splitting a service out

We only pulled a module out into its own service when at least one of these was true, and ideally more than one:

It needed to scale independently — a video transcoding job doing CPU-heavy work shouldn't share a fleet with a lightweight API responding to user requests
It needed a genuinely different deployment cadence — a fraud-detection model that gets retrained weekly shouldn't be coupled to a deploy pipeline that ships five times a day
A separate team owned it and needed to move without coordinating every release with everyone else

The catalog and search functionality on that third project eventually became its own service, not because we drew a diagram that said it should, but because it was genuinely CPU and memory bound in a way the rest of the app wasn't, and it needed its own scaling policy in production. The billing module stayed inside the monolith for over two years because none of those three conditions applied to it, and splitting it out would have added network calls and deployment complexity for zero real benefit.

What I'd tell a team starting out today

Start with a monolith. Enforce module boundaries inside it like you mean it — this is the discipline that actually determines whether a future split will be easy or a nightmare, far more than the choice of monolith versus microservices itself. Extract a service only when you have a concrete, specific reason tied to scaling, deployment cadence, or team ownership, not because a conference talk made distributed systems sound inevitable. The architecture that's right for a company at 200 engineers is very often actively wrong for a company at 8, and copying the endpoint architecture of a company ten times your size is optimizing for a problem you don't have yet.