Microservices: The Coordination Tax Nobody Talks About

Twilio Segment did everything “right.”

Services per destination. Separate queues. Individual repos. Shared libraries.

On paper? Clean. In reality? Coordination hell.

Three engineers spent most of their time just keeping the system alive. Velocity dropped. Defects exploded. On-call was brutal.

The problem wasn’t microservices. It was the coordination tax.

The Hidden Cost of Distribution

Every new destination meant:

• Another service to deploy
• Another repo to maintain
• Another version of “shared” libraries drifting out of sync
• Another scaling profile to tune by hand

This is the dirty secret of microservices that architects don’t talk about in conference talks. The architecture diagrams look beautiful. The reality is a web of dependencies that require constant care and feeding.

The Segment engineering blog post on this migration is worth reading in full, but the key insight is damning: microservices created organizational complexity that dwarfed any technical benefits.

They Did the Unpopular Thing

So they collapsed 140 microservices into a single, well-designed monolith.

The results were dramatic:

• Deployment complexity dropped by orders of magnitude
• Three engineers went from maintenance to building features
• On-call incidents plummeted
• Developer velocity increased significantly

Microservices Are a Coordination Strategy, Not a Scaling Strategy

Here’s the insight most teams miss: Microservices are a coordination strategy, not a scaling strategy.

They make sense when:

• You have multiple teams that need to work independently
• Different services have genuinely different scaling characteristics
• You’re at a scale where organizational coordination is your bottleneck

They don’t make sense when:

• A small team owns the entire system
• Services share more code than they don’t
• You’re optimizing for hypothetical scale you haven’t hit

The Warning Signs

Here’s what to watch for in your own architecture:

1. The “Shared Library” Smell When your microservices depend heavily on shared libraries, you’ve just built a distributed monolith with network calls instead of function calls. Worse in every way.

2. The “Three Engineers Keeping It Alive” Pattern If your operational overhead is consuming your best people, something is wrong. Infrastructure should enable building, not consume all the building capacity.

3. The “One Team, Many Services” Anti-Pattern If the same team owns multiple services, you’re paying coordination tax without getting coordination benefits.

4. The “Deploy Everything Together” Test If you have to deploy multiple services together for most changes, you don’t really have microservices. You have a distributed monolith.

When Microservices Make Sense

I’m not anti-microservices. They’re the right choice in specific situations:

• Amazon/Netflix scale, when you have thousands of engineers and genuine scale challenges
• Genuinely independent domains, when services truly don’t share data or logic
• Different technology needs, when one service needs Python ML and another needs Go for performance
• Regulatory boundaries, when data must be isolated for compliance reasons

But these situations are rarer than the industry pretends.

The Monolith Renaissance

We’re seeing a monolith renaissance, and it’s healthy. Teams are realizing that a well-designed monolith is easier to:

• Deploy
• Debug
• Test
• Reason about
• Refactor

DHH has written extensively about Basecamp/Hey’s success with a monolithic architecture at significant scale. The 37signals team ships fast with a small team precisely because they don’t have microservices overhead.

My Recommendation

For most startups and small teams:

1. Start with a monolith. Always. You can extract services later when you have data about what actually needs to be separate.

2. Use modular architecture within the monolith. Draw boundaries in code, not in deployment. This gives you the organizational benefits without the operational cost.

3. Extract only when painful. Wait until you have real pain before adding distribution complexity. Hypothetical scale isn’t a reason to add real complexity.

4. Measure the coordination tax. Track how much engineering time goes to keeping the system alive vs. building features. If the ratio is wrong, simplify.

The Segment story isn’t about microservices being bad. It’s about choosing the right architecture for your context. And for most teams, that context doesn’t require distributed systems complexity.

Don’t let architecture astronauts convince you that your 5-person startup needs microservices. You need to ship.