Everyone’s rushing to microservices. Most shouldn’t.

I’ve watched teams tear apart working monoliths because “Netflix does it” or “microservices scale better.” Then they spend 6 months debugging distributed systems failures they never had before.

The Microservices Hype Cycle

2015: “Monoliths are dead!” 2020: “Modular monoliths are back!” 2025: “Actually, it depends…”

We’ve come full circle. Good.

When Monoliths Win

Start with a monolith if:

  • Your team is < 10 engineers
  • You’re not Google/Amazon scale (you’re probably not)
  • You value shipping features over architecting systems

Deployment? One binary. Debugging? Stack traces work. Transactions? ACID by default.

Simple wins.

When Microservices Make Sense

Go microservices when:

  • You have 50+ engineers stepping on each other
  • Different services need different scaling (rare in practice)
  • Team autonomy > system simplicity

But be ready for:

  • Distributed debugging nightmares
  • Eventual consistency everywhere
  • DevOps complexity 10x
  • “Works on my service” bugs

The Middle Ground: Modular Monolith

Most teams should build modular monoliths:

  • Clear module boundaries (like microservices)
  • Shared process (like monoliths)
  • Can extract services later if needed

Start simple. Extract when pain justifies complexity.

Conclusion

Architecture isn’t about trends—it’s about trade-offs. Microservices solve organizational problems, not technical ones. If your org doesn’t have those problems, why pay the cost?

Build boring technology. Ship features. Refactor when you must.

Darkflow writes about system design with a healthy dose of skepticism.