You Don't Need Microservices (Yet): A Reality Check for Devs

How Premature Architecture Decisions Slow Down Teams and Burn Engineering Budget

Every few months, I see the same conversation play out in engineering teams.

A new project kicks off. The team is excited. Someone opens the architecture discussion and says: "We should probably do microservices".

Nobody disagrees. Microservices are what serious companies do. Netflix does it. Amazon does it. Surely we should too.

Six months later, the team is spending more time debugging distributed systems, writing boilerplate for inter-service communication, and managing deployment pipelines than they are building features. Velocity is down. Morale is shaky. The MVP is late.

The architecture is impressive. The product is not shipped.

This article isn't anti-microservices. Microservices are the right answer, for some teams, at some stage, solving some problems. The goal here is to give you an honest framework for knowing whether you're at that stage, and what to do if you're not.

TL;DR

• Microservices solve real problems, but only problems that come with scale. If you don't have those problems yet, you're paying the cost without getting the benefit.
• A well-structured monolith is not a compromise. It's often the fastest, most maintainable architecture for teams under a certain size and complexity threshold.
• There are concrete signals that tell you when it's time to split. Before those signals appear, premature decomposition is one of the most expensive architectural mistakes a team can make.

Table of Contents

• What Microservices Actually Solve
• What a Well-Structured Monolith Looks Like
• The Real Cost of Premature Decomposition
• Monolith vs Microservices: A Concrete Comparison
• Rules of Thumb: When to Actually Consider Splitting
• The Decision Framework
• When Microservices Are the Right Call
• Final Thoughts

What Microservices Actually Solve

Before deciding whether you need microservices, it's worth being precise about what problem they were invented to solve.

Microservices emerged as an answer to a very specific set of pressures that appear at scale:

Independent deployability. When hundreds of developers are working on the same codebase, deploying a change to the checkout flow shouldn't require coordinating with the team working on the recommendation engine. Microservices let teams deploy independently.

Fault isolation. In a monolith, an unhandled exception in one part of the system can take down the entire application. In a microservices architecture, a failure in the notifications service doesn't affect the payment service.

Independent scalability. If your image processing service needs ten times the compute of your user auth service, a microservices architecture lets you scale them independently. In a monolith, you scale everything or nothing.

Technology heterogeneity. Different services can use different languages, runtimes, or databases if the problem demands it.

These are genuine, valuable properties.

The question is: do you have the problems these properties solve?

If you have five developers, one product, and a user base that hasn't hit its first scaling wall, the answer is almost certainly no.

What a Well-Structured Monolith Looks Like

"Monolith" has become a dirty word in engineering culture. It shouldn't be.

The alternative to microservices isn't a chaotic mess of spaghetti code. It's a modular monolith: a single deployable unit, internally organized around clearly separated domains.

Here's what that looks like for a simple e-commerce application:

src/
├── modules/
│   ├── orders/
│   │   ├── orders.controller.ts
│   │   ├── orders.service.ts
│   │   ├── orders.repository.ts
│   │   └── orders.types.ts
│   │
│   ├── products/
│   │   ├── products.controller.ts
│   │   ├── products.service.ts
│   │   ├── products.repository.ts
│   │   └── products.types.ts
│   │
│   ├── users/
│   │   ├── users.controller.ts
│   │   ├── users.service.ts
│   │   ├── users.repository.ts
│   │   └── users.types.ts
│   │
│   └── payments/
│       ├── payments.controller.ts
│       ├── payments.service.ts
│       ├── payments.repository.ts
│       └── payments.types.ts
│
├── shared/
│   ├── database/
│   ├── middleware/
│   └── utils/
│
└── app.ts

Each module owns its domain. The orders module doesn't reach into the products database directly, it calls productService through a defined interface. The boundaries are logical, not physical.

// src/modules/orders/orders.service.ts

import { productService } from '@/modules/products/products.service'
import { paymentService } from '@/modules/payments/payments.service'
import { Order, CreateOrderPayload } from './orders.types'
import { ordersRepository } from './orders.repository'

export const ordersService = {
  async create(payload: CreateOrderPayload): Promise<Order> {
    // Validate product exists and has stock
    const product = await productService.getById(payload.productId)

    if (product.stock < payload.quantity) {
      throw new Error('Insufficient stock')
    }

    // Process payment
    const payment = await paymentService.charge({
      amount: product.price * payload.quantity,
      currency: 'EUR',
      customerId: payload.customerId,
    })

    // Create the order
    const order = await ordersRepository.create({
      ...payload,
      paymentId: payment.id,
      status: 'confirmed',
    })

    // Decrement stock
    await productService.decrementStock(payload.productId, payload.quantity)

    return order
  },
}

This is a direct function call. It's fast, it's simple, it's easy to trace in a debugger, and it's testable by mocking productService and paymentService.

No HTTP overhead. No serialization. No network failures to handle. No service discovery.

The same logic, across a microservices boundary, looks very different.

The Real Cost of Premature Decomposition

Before we look at the microservices version, let's be explicit about what you're taking on when you split prematurely.

Distributed systems complexity. Once your services communicate over a network, you have an entirely new class of problems: latency, partial failures, network timeouts, retry logic, idempotency. These aren't theoretical, they show up constantly in production, and they're significantly harder to debug than in-process errors.

Operational overhead. Each service needs its own CI/CD pipeline, its own deployment configuration, its own monitoring and alerting setup. For a two-person team, this is not a few hours of work, it's weeks, and it never really ends.

Development friction. Running the entire application locally now means running five (or fifteen) services simultaneously. Developer experience degrades. Onboarding new teammates takes longer.

Data consistency challenges. In a monolith, a database transaction either succeeds or fails atomically. Across services, you have to implement distributed transactions or accept eventual consistency, both of which add significant complexity to every operation that touches multiple domains.

The "wrong seams" problem. Domain boundaries that seem obvious on day one are often wrong by month six. In a monolith, reorganizing a module is a refactoring task. In a microservices architecture, it's a cross-service migration, which means coordination between teams, versioned APIs, and backward compatibility concerns.

Martin Fowler, one of the most authoritative voices on this topic, coined the term "distributed monolith" for what often happens when teams split prematurely: you get all the operational complexity of microservices, with none of the benefits, because the services are still tightly coupled through synchronous calls and shared data.

Monolith vs Microservices: A Concrete Comparison

Let's make this tangible. Same feature, creating an order in our e-commerce app, implemented both ways.

In the modular monolith

We already saw this above. The ordersService calls productService and paymentService directly. The entire operation is one function call, one database transaction, and one stack trace if something goes wrong.

// Creating an order, one direct call
const order = await ordersService.create({
  productId: 'prod-123',
  quantity: 2,
  customerId: 'user-456',
})

If this fails, the error propagates synchronously. The stack trace tells you exactly where it failed. The database transaction ensures nothing is partially committed.

In a microservices architecture

The same operation now crosses three network boundaries:

// src/services/orders-service/src/orders.service.ts

import { ApiError } from '@/lib/errors'

export const ordersService = {
  async create(payload: CreateOrderPayload): Promise<Order> {
    // HTTP call to products-service
    const productRes = await fetch(
      `${PRODUCTS_SERVICE_URL}/products/${payload.productId}`
    )
    if (!productRes.ok) throw new ApiError(productRes.status, 'Product fetch failed')
    const product = await productRes.json()

    if (product.stock < payload.quantity) {
      throw new Error('Insufficient stock')
    }

    // HTTP call to payments-service
    const paymentRes = await fetch(`${PAYMENTS_SERVICE_URL}/payments`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        amount: product.price * payload.quantity,
        currency: 'EUR',
        customerId: payload.customerId,
      }),
    })
    if (!paymentRes.ok) throw new ApiError(paymentRes.status, 'Payment failed')
    const payment = await paymentRes.json()

    // Create the order locally
    const order = await ordersRepository.create({
      ...payload,
      paymentId: payment.id,
      status: 'confirmed',
    })

    // HTTP call back to products-service to update stock
    const stockRes = await fetch(
      `${PRODUCTS_SERVICE_URL}/products/${payload.productId}/stock`,
      {
        method: 'PATCH',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ decrement: payload.quantity }),
      }
    )
    if (!stockRes.ok) throw new ApiError(stockRes.status, 'Stock update failed')

    return order
  },
}

Now ask yourself what happens if the payment succeeds but the stock update call fails.

The payment has been charged. The order has been created. But the stock hasn't been decremented. You now have an inconsistency in your data, and no database transaction to roll it back for you.

Solving this correctly requires implementing a saga pattern or distributed transaction, which is a substantial engineering investment, and a source of bugs that are notoriously difficult to reproduce and fix.

This is the complexity you're signing up for when you split before you need to.

Rules of Thumb: When to Actually Consider Splitting

There are real signals that indicate a team is approaching the point where microservices start making sense. Here are the ones that consistently hold up in practice.

The Conway's Law signal.
Your team is growing, and different groups of developers are consistently working on different parts of the system with little overlap. Conway's Law tells us that system architecture tends to mirror team communication structure, so if your team has naturally split into a "payments team" and a "catalog team", the architecture probably should too, eventually.

Rule of thumb: consider splitting when you have two or more teams that consistently own distinct domains and need to deploy independently.

The scaling bottleneck signal.
A specific part of your system needs to scale independently from the rest, and that difference is significant enough to justify the operational overhead. Your image processing pipeline needs fifty instances; your user auth service needs two.

Rule of thumb: consider splitting when you've identified a specific performance bottleneck that can't be solved by vertical scaling or database optimization.

The deployment coupling signal.
Deploying a change to one domain consistently requires coordinating with other teams or causes unrelated failures. The deploy process has become a source of organizational friction, not just technical friction.

Rule of thumb: consider splitting when deployment coupling is measurably slowing down multiple teams on a recurring basis, not as a one-off event.

The failure isolation signal.
A non-critical part of your system (notifications, recommendations, reporting) is causing outages in critical paths (checkout, auth). The blast radius of failures is unacceptably large.

Rule of thumb: consider splitting when a failure in a low-priority domain is regularly impacting high-priority ones, and the fix isn't a code change but an architecture change.

The team size signal.
A widely cited heuristic, often attributed to Werner Vogels at Amazon, is the two-pizza rule: if you can't feed the team working on a service with two pizzas, the service is too big. The inverse is also true: if your entire engineering org fits at one table, microservices are probably not your problem yet.

Rule of thumb: teams under ~8–10 engineers rarely have the operational capacity to manage a microservices architecture well. The overhead consumes the productivity gains.

The Decision Framework

Before making any architectural decision toward microservices, run through these questions honestly:

1. What specific problem are you solving?

Write it down in one sentence. If the answer is "we want to be like Netflix" or "microservices are best practice", that's not a problem, it's a preference. Come back when you have a concrete problem.

2. Have you felt the pain of the alternative?

The best time to split a monolith is when it's actively hurting you. Slow deploys, scaling bottlenecks, team coupling, these are real pain. Splitting to avoid hypothetical future pain usually creates real present pain.

3. Do you have the operational maturity?

Microservices require investment in infrastructure: container orchestration (Kubernetes), service discovery, distributed tracing, centralized logging, health checks, circuit breakers. If your team doesn't have experience running these, plan for months of setup before you see the first benefit.

4. Are your domain boundaries stable?

If you're still figuring out what your product is, your domain model is still changing. Splitting along boundaries that will shift in three months is worse than not splitting at all.

5. Can you start with a modular monolith first?

A modular monolith with clean internal boundaries is a microservices architecture waiting to be extracted. If you've built the modules correctly, the split is a deployment change, not a rewrite. Start there.

Monolith vs Microservices Decision Matrix

When Microservices Are the Right Call

To be completely clear: there are scenarios where microservices are the right architecture from early on.

When compliance requires hard data isolation. If regulations require that payment data is physically isolated from user data with separate access controls and audit logs, separate services may be a compliance requirement, not an architectural preference.

When parts of the system have radically different SLAs. If your real-time trading engine needs 99.999% uptime and your reporting dashboard can tolerate downtime, running them in the same process is a liability.

When you're integrating genuinely independent third-party systems. An event-driven architecture where a service wraps a third-party provider (a payment gateway, a shipping API) and exposes a clean internal interface is a legitimate use of service decomposition from day one.

When you're building a platform with external integrations. If your architecture will expose APIs to external developers and those APIs need to evolve independently, service boundaries help.

The pattern in all of these is the same: there's a concrete, specific constraint that the architecture is responding to. Not a preference. Not a pattern borrowed from a company with different problems at a different scale.

Final Thoughts

Architecture decisions have a compounding effect on team velocity, in both directions.

The right architecture at the right time makes everything else faster: onboarding, debugging, deploying, iterating. The wrong architecture at the wrong time turns every feature into an infrastructure problem.

Microservices are powerful. They're also expensive. The teams that get the most out of them are the ones who waited until they had the problems microservices solve, and who built clean internal boundaries in their monolith in the meantime.

If you're in the early stages of a product, the most valuable architectural investment you can make is usually not splitting your system apart. It's understanding your domain well enough that, when the time comes to split, you know exactly where to cut.

Start simple. Feel the pain. Split deliberately.

Where is your team on this spectrum right now?

Are you running a monolith that's starting to show its limits, or did you go microservices early and live to regret it, or not? Drop your experience in the comments. The architecture conversations in the comments section are always the most useful part of these articles.

If this was useful, a ❤️ or a 🦄 helps it reach more developers who are about to make this decision.
And if you want the next article in the series when it drops, hit follow.