The microservices trap almost nobody talks about

An eight-person team 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 if one of them fails, the whole thing falls over anyway. You don't have microservices: you have a distributed monolith. It's the worst architecture you can have.

The video above, from the channel The Serious CTO, hits a nerve we see every time we land on a modernization project at SISCON: teams that bought the microservices narrative without having the scale, the organization or the platform muscle to back it up. The result isn't a more agile system. It's a more expensive, more fragile and slower-to-change one.

Microservices aren't a scaling strategy. They're a coordination strategy.

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

If your organization has a twelve-person engineering team, you don't have a 200-team coordination problem. You have a twelve-people 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 your network, your operations, and your team's processes. This is what some call the coordination tax, and it's 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 in itself. Pipelines, registries, contract-version management, test environments with N services up. You need a dedicated platform team.
• Cross-service debugging is an extreme sport. Without solid distributed tracing, finding where a transaction broke can take days.
• Distributed transactions are a myth. What used to be an ACID transaction becomes a saga pattern with compensations, idempotency and inconsistent states the business has to learn to tolerate.
• Your cloud bill explodes. CNCF surveys and public reports from companies that migrated consistently show that infrastructure costs rise after adopting microservices — more nodes, more networking, more observability, more storage.

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

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

• To release a feature you need to deploy 3, 4 or 5 services in a specific order.
• Services share the same database (or worse: separate tables in the same logical schema).
• An outage in the "least important" service brings the rest down 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 is clearly "the owner" of 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 organization size.

The honest questions to ask before splitting anything

Before you fragment a system, it pays to seriously answer three questions — with "because it's trendy" not counting as a valid answer:

1. What real business problem does this solve? If the answer is "we want to modernize" or "we want to be in cloud," that's not enough. Legitimate reasons: a module has a radically different lifecycle from the rest (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 secrets management, and clear API-versioning policies. If you don't have this before starting, you're going to learn it in production — and it's going to hurt.

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

The alternative rarely proposed: the modular monolith

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

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

When does it actually make sense to split?

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 vs. 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's a real dedicated team with a clearly bounded domain. Not "a team that touches four services," but a team that owns a complete bounded context.
• You're doing strangler fig on a legacy system. Here "microservices" are a migration tactic, not the end architecture.

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

Software architecture isn't a fashion. It's a decision you'll 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're 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's architecture. Often it's discipline, observability or process. And if you're 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.