Microservices too early: the tax you pay before you need them

The diagram usually arrives before the users do. Twelve boxes: user-service, auth-service, notification-service, payments, billing, email, webhooks, analytics, search, media, a config service, and an API gateway in front of the lot. Behind it are three engineers and a few hundred customers. Every feature touches three services, local development needs a dozen containers, and whoever set up the cluster now spends most of the week keeping it alive rather than building anything.

Nobody chose that outcome. Each split looked sensible on the day it happened. The cost shows up later, spread thinly across every task, which is what makes it so hard to argue about without numbers.

I have worked both sides of this. I joined Acefone while it was migrating from a PHP monolith to MERN microservices, took the greenfield work, and defined the service patterns the new services follow, including Interaction Hub, which handles voice, WhatsApp messaging and WhatsApp Calls in one inbox. I also built EMPRO alone as one well-understood Node service with MongoDB, and it ran at 99.9% uptime. Both were right for where they were. The useful skill is telling which situation you are actually in, so this post puts numbers on the cost, and ends with a scorecard you can fill in.

What services actually buy you

Two things, mainly. Independent deployment: a team can ship its part without coordinating a release with everyone else. Independent scaling: the part that needs sixteen CPUs and a GPU can have them without the rest of the application following it around. Fault isolation and the freedom to use a different language are real too, though they show up less often than people expect.

Each of those solves a problem that only exists at a certain size. With forty engineers in one pipeline, a broken main branch blocks everybody and release coordination becomes a job. With five engineers, that coordination is a message in a channel. Buying the cure before the disease means you pay for the medicine every day, forever.

Fowler put the same idea more carefully in Microservice Premium: "microservices introduce complexity on their own account. This adds a premium to a project's cost and risk", and his primary guideline is to not "even consider microservices unless you have a system that's too complex to manage as a monolith". The word to notice is manage. Not "big". Not "impressive on a diagram".

The distributed tax

The price of a split has three parts, and the one everyone talks about is the smallest.

The first part is availability, and it is pure arithmetic. When a request needs every service on its path to answer, the availabilities multiply, exactly like the composite SLA of any dependency chain. Four services at 99.9% each give 0.999⁴, which is 99.60%: about 2 hours 55 minutes of expected downtime a month, against 43 minutes 50 seconds for a single service at the same level.

The second part is the slow tail, and it is the same multiplication in a different suit. Dean and Barroso's The Tail at Scale puts it starkly: a server that "typically responds in 10ms but with a 99th-percentile latency of one second" makes one user request in a hundred slow on its own, but if "a user request must collect responses from 100 such servers in parallel, then 63% of user requests will take more than one second". Four services is not a hundred, but the direction is the same: about 3.9% of requests will hit at least one hop having a bad moment, and a request is only as fast as its slowest part.

The third part is the network itself, and this is the one people argue about. It is cheap. A round trip inside the same data centre is about half a millisecond in Jeff Dean's numbers, so three extra hops cost you around 1.5 ms of wire time. Nobody's product died of 1.5 ms. What costs is everything you have to build around those hops: a timeout on each call, a retry policy, idempotency so that retries are safe, a decision about what to render when one call fails, and a way to trace one request across four processes when it does.

Here is that in code. The version that lives in one process is a query:

async function orderHistory(userId: string) {
  return db.query(
    `SELECT o.id, o.created_at, o.total, p.name, p.image_url
       FROM orders o
       JOIN products p ON p.id = o.product_id
      WHERE o.user_id = $1
      ORDER BY o.created_at DESC
      LIMIT 20`,
    [userId],
  )
}

The version across services is a distributed join that you now maintain by hand:

async function orderHistory(userId: string) {
  const [orders, user] = await Promise.all([
    orderClient.listByUser(userId, { limit: 20 }),
    userClient.get(userId),
  ])

  const products = await Promise.all(
    orders.map((order) => productClient.get(order.productId)),
  )

  return orders.map((order, i) => ({ ...order, product: products[i], user }))
}

The usual answers are a batch endpoint, productClient.getMany(ids), which is one more API to design, version and keep compatible, or a local copy of product names inside the order service, which means accepting that the copy is sometimes stale. Both are fine. Both are work that the JOIN did for free.

Monolith first, modular always

MonolithFirst, from June 2015, reports a pattern that has aged well: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up", while "almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble." The reason is boundaries. Services "only work well if you come up with good, stable boundaries between the services", and "even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning."

That is the crux. A service boundary is a guess about your domain, cast in network protocol. Move a responsibility between modules in a monolith and it is a refactor your IDE can do. Move it between services and it is two repositories, two deploys, a migration and a compatibility window.

The alternative to guessing early is not a big ball of mud. It is a modular monolith: one deployable, with boundaries that tooling actually enforces. Shopify has written the best public account of this. Their 2019 post describes "one of the largest Ruby on Rails codebases in existence", worked on "for over a decade by more than a thousand developers", and defines the pattern plainly: "A modular monolith is a system where all of the code powers a single application and there are strictly enforced boundaries between different domains." They rejected microservices because they would mean "maintaining multiple different test & deployment pipelines and infrastructural overhead for each service".

The 2020 follow-up is the practical one: 2.8 million lines of Ruby, 37 components, and a static analysis tool, packwerk, that rejects changes that "break the dependency graph or component encapsulation before they get merged into our main branch". That is the part people skip. Folders are not boundaries. A rule in CI is a boundary.

src/
  modules/
    orders/        index.ts      ← the only thing other modules may import
                   orders.service.ts
                   orders.repository.ts   ← owns the orders tables, nothing else touches them
    products/      index.ts
    payments/      index.ts
  shared/          database, auth, config
  app.ts

Two rules make this real: a module may only be imported through its index, and a module's tables belong to it alone. Enforce both in CI and you have the thing that makes extraction cheap later, because the only question left on the day you split is deployment.

What to have in place before the first extraction

Fowler's Microservice Prerequisites, from 2014, lists three: rapid provisioning, so "you should be able to fire up a new server in a matter of hours"; basic monitoring, because "it's essential that a monitoring regime is in place to detect serious problems quickly"; and rapid application deployment. If standing up a new service takes a fortnight of ticket-raising, you will pay that fortnight per service.

I would add a fourth, from my own mistake. If I could change one thing about Interaction Hub at Acefone, I would have put the interaction event schema under contract tests on day one. We got versioning wrong and paid for it twice during rollout. Between modules in one process, a wrong assumption about a payload is a failing build. Between services, it is a production incident with two teams in the call, and the second one you fix is more expensive than the first, because by then other consumers depend on the shape you are trying to change.

The other prerequisite is being able to follow one request across processes. In a monolith, a stack trace tells you the whole story. Across services you need a request ID on every log line at minimum and real tracing before long, which is the difference between logging a lot and being able to answer a question, the subject of logging everything and learning nothing.

Score your own readiness

Two things decide this, and they are independent. Pressure is how badly you need what services provide. Readiness is whether you can afford to run them. High pressure with low readiness is how teams end up with twelve services and no way to debug them.

The defaults describe a common seed-stage team: six to fifteen engineers, weekly deploys, tests that gate merges, logs searched by hand, and none of the rest in place. That scores 10 for pressure and 19 for readiness, which is a straightforward "stay a monolith". Now tick the two that change everything, a measured bottleneck and teams blocking each other weekly, and set the team to 16 to 40. Pressure jumps to 70, readiness is still 19, and the answer becomes a modular monolith first: the need is real, the ability to operate services is not there yet, and the gap list is the work.

The tax panel underneath uses the order-history path: four services at 99.9% each, which is 99.60%, about 2 hours 55 minutes a month, 3.9% of requests hitting a slow tail somewhere, and 1.5 ms of actual wire time.

When extracting one service is the right call

Three reasons hold up. A measured bottleneck, where one workload needs different hardware or scales on a different curve, such as video transcoding or model inference. A different runtime or release cadence, such as a Python model that ships daily beside a Node application that ships weekly. And regulatory isolation: Shopify extracted credit card vaulting for exactly that reason, alongside storefront rendering for performance, while keeping the rest in the monolith.

When you do it, go one at a time, and use the strangler fig approach: new behaviour is built beside the old system, and behaviour moves across a piece at a time rather than in one cutover. Move the data ownership first, keep the old path working until the new one is proven, and then delete the old path properly instead of leaving both.

It is worth knowing the story runs the other way too. Segment described going back to a monolith in 2018 after their per-destination services grew past 140, with three full-time engineers "spending most of their time just keeping the system alive" and shared library changes so risky that versions quietly diverged. After consolidating, they made 46 improvements to those shared libraries in a year, against 32 in the year of the microservice architecture.

And sometimes the answer is not services at all. At TRIBE, what let a small team go from nothing to over 100,000 users was not splitting the backend up. It was moving expensive work off the request path into BullMQ and AWS SQS, and running live prices over Socket.io on Redis pub/sub. A queue gives you independent scaling for the slow part without giving you a distributed system to debug, though it brings its own arithmetic, which is the backlog problem.

The short version

Microservices solve coordination and scaling problems that appear at a certain size. Below that size you pay the premium and get nothing back: availability multiplies down, slow tails compound, and every call needs a timeout, a retry and a story for partial failure. The wire time is the cheap part.

Build the modular monolith instead. One deployable, boundaries enforced in CI, each module owning its own tables. Then when a measured reason turns up, extract that one service, with contract tests on the events from day one, and see how it goes before you do the next one.