Stop Overengineering Everything

You know what scales really well? A monolith.#

I need to say this because the internet won't: most apps don't need microservices.

Your startup with 500 users doesn't need Kubernetes. Your side project doesn't need an event-driven architecture. Your blog doesn't need a distributed cache.

But every junior dev I interview talks about their "microservices architecture" for a to-do app. We need to stop.

The overengineering checklist#

Before you add complexity, ask yourself:

• Do I have more than 10 engineers? No? Monolith.
• Do different parts of my app scale independently? No? Monolith.
• Am I deploying different features on different schedules? No? Monolith.
• Is my database struggling? Add an index before you add a service.

Shopify runs on a monolith. So did GitHub for years. Basecamp still does. These aren't small companies.

The real cost of microservices#

Nobody talks about this part:

• Network calls instead of function calls. Every service boundary is a latency penalty and a failure point.
• Distributed transactions. Have fun with saga patterns when all you needed was a database transaction.
• Deployment complexity. Instead of deploying one thing, you're deploying twelve things and praying they're compatible.
• Debugging across services. A bug that would take 5 minutes to find in a monolith takes 2 hours across 6 services and 4 log aggregators.

When to ACTUALLY use microservices#

• You have 50+ engineers and they're stepping on each other
• One part of your system needs to scale 100x while the rest stays small
• You're integrating systems built in different languages
• You have a compliance requirement to isolate certain data

That's basically it.

The right amount of architecture#

Here's my rule: start with the simplest thing that could work, and add complexity only when you feel the pain.

Don't add caching until your queries are slow. Don't add a queue until your API is timing out. Don't split into services until your team can't deploy without conflicts.

Three lines of duplicated code is better than a premature abstraction. A slow monolith is better than a broken microservice mesh.

See the difference#

Want to see what an appropriately simple architecture looks like vs. an overengineered one? Try comparing them:

Go to Codelit, turn on Compare Mode, and type "monolith vs microservices for a simple SaaS app." You'll see exactly how much unnecessary complexity microservices add for a small team.