The microservices trap almost nobody tells you about

A team of eight maintains twenty microservices. Every release touches four repos. A transaction that used to be a single database call now travels through five services, two queues and a service mesh. And even so, if one fails, everything goes down. You don't have microservices: you have a distributed monolith. And that is the worst possible architecture.

The video above, from the channel The Serious CTO, puts a finger on a sore spot we run into at SISCON every time we land on a modernization project: teams that bought into the microservices pitch without having the scale, the organization or the platform muscle to sustain it. The result is not a more agile system. It is a more expensive, more fragile and slower-to-change one.

Microservices are not a scaling strategy. They are a coordination strategy.

This is the market's central confusion. Microservices were not born to "scale your traffic" — a well-built monolith handles orders of magnitude more load than most Mexican companies will ever see. Microservices were born at Amazon, Netflix and Spotify to solve a people problem: how to let 200 teams ship software independently without stepping on each other.

If your organization has a team of twelve developers, you don't have a coordination problem across 200 teams. You have a twelve-person problem. And for twelve people, a well-structured monolith is objectively better: one deploy, one transaction, one log, one database. Operational complexity collapses.

The "coordination tax" nobody warned you about

When you split a system into N services, you don't eliminate complexity — you move it. It leaves your code and enters the network, the operation and your team's processes. This is what some people call the coordination tax, and it is almost always underestimated in the original business case:

• Every new feature touches several repos. A user story that used to be one PR becomes four coordinated PRs, with merge-order dependencies.
• Your CI/CD becomes a system of its own. Pipelines, registries, contract version management, test environments with N services running. You need a dedicated platform team.
• Cross-service debugging is an extreme sport. Without well-implemented distributed tracing, finding where a transaction broke can take days.
• Distributed transactions are a myth. What you had as an ACID transaction becomes a saga pattern with compensations, idempotency and inconsistent states the business has to learn to tolerate.
• Your cloud bill goes up. CNCF surveys and public reports from companies that migrated consistently show infrastructure costs rising after adopting microservices — more nodes, more networking, more observability, more storage.

What a "distributed monolith" looks like (and why it is the worst of both worlds)

The distributed monolith is what happens when you split the code but don't split the coupling. The signs are brutal and almost always the same:

• To ship a feature you need to deploy 3, 4 or 5 services in a specific order.
• The services share the same database (or worse: different tables in the same logical schema).
• An outage in the "least important" service takes down the rest because someone calls it synchronously in the critical path.
• Contracts between services change without versioning, so a change in one breaks the others.
• No team clearly "owns" a service — everyone edits everything.

If that sounds familiar, you don't have an implementation problem. You have an architecture problem: you applied the wrong pattern to the wrong size of organization.

The honest question before splitting anything

Before breaking a system apart, it is worth seriously answering three questions — with "because it's fashionable" not counting as a valid answer:

1. What is the real business problem this solves? If the answer is "we want to modernize" or "we want to be in the cloud", that is not reason enough. Legitimate reasons: a module has a radically different lifecycle from the rest (it changes 10x faster or 10x slower), a module has very different scaling or compliance requirements, or there are physically separated teams that need to operate independently.

2. Do we have the platform muscle to sustain it? Microservices require serious observability (correlated logs, metrics and traces), mature CI/CD, a service mesh or equivalent, centralized secret management, and clear API versioning policies. If you don't have this before you start, you are going to learn it in production — and it will hurt.

3. Does our organizational structure match this architecture? Conway's law is relentless: you end up building systems that mirror your organization's communication. If you have a single development team, you are going to build a monolith in disguise. If you want real microservices, you first need real teams with owners, OKRs and autonomy.

The alternative that rarely gets proposed: the modular monolith

Between "everything in one blob of code" and "microservices from day one" there is a middle ground where most successful systems live: the modular monolith. It is one process, one deploy, one database — but internally it is divided into modules with clear boundaries, where one module cannot reach into another's internals.

The upside: you keep the operational simplicity of a monolith (one log, one deploy, ACID transactions, local debugging), but with the discipline of internal boundaries that means when the day comes that a module genuinely needs to live apart, you can extract it with little pain. Companies like Shopify have documented for years how this architecture took them a very long way before they needed to extract services.

When does splitting actually make sense?

There are real scenarios where microservices are the right answer — we don't want to fall into the opposite extreme. The most common ones we see in serious projects:

• A module needs to scale very differently from the rest. For example, a compute-intensive engine that needs GPUs versus a web layer that needs many small replicas.
• A module has regulatory or isolation requirements. Sensitive personal data, modules subject to independent audits, segregation by country.
• There is a real dedicated team with a clearly delimited domain. Not "a team that touches four services", but a team that owns a complete bounded context.
• You are doing strangler fig on a legacy system. Here the "microservices" are a migration tactic, not the final architecture.

The conclusion that doesn't sell courses but does build systems that last

Software architecture is not a fashion. It is a decision you are going to live with for five to ten years. Adopting microservices without having the problem, the scale or the team to sustain them guarantees one thing: paying the full cost of distributed complexity without receiving any of the benefits.

If you are starting a new system, begin with a well-designed modular monolith. If you already have a monolith that hurts, don't assume microservices are the answer — first understand why it hurts. Sometimes it is architecture. Many times it is discipline, observability or process. And if you are already in a distributed monolith, the best thing you can do is have the courage to reconsolidate what should never have been split.

Video source: "The Microservices Scam Nobody Talks About" — The Serious CTO. Watch on YouTube.