I love the idea of microservices. When there’s a problem on your website, you don’t need to fix and redeploy your entire codebase. If the issue only affects your authentication service, you can deploy just that one component and call it a day. You’ve isolated the authentication feature into an independent microservice that can be managed and maintained on its own.

That’s the theory. The reality is often different.

Microservices are a software architecture style where an application is built as a collection of small, independent, and loosely coupled services that communicate with each other. The "micro" in the name implies they should be small, and they usually start that way.

When you first adopt this philosophy, all services are genuinely small and build incredibly fast. At this stage, you start questioning why you ever thought working on a monolith was a good idea. I love working on applications where the time between pushing a change and seeing its effect is minimal. The feedback loop is tight, deployments are quick, and each service feels manageable.

And then, they grow

But I’ve worked long enough in companies adopting this style to watch the transformation. Small becomes complex. Fast becomes extremely slow. Cheap becomes resource-intensive.

Microservices start small, then they grow. And grow. And the benefits you once enjoyed start to vanish.

For example, your authentication service starts with just login and logout. Then you add password reset. Then OAuth integration. Then multi-factor authentication. Then session management improvements. Then API key handling. Before you know it, your "micro" service has ballooned to thousands of lines of code, multiple database tables, and complex business logic.

When you find yourself increasing the memory allocation on your Lambda functions by 2x or 3x, you’ve reached this stage. The service that once spun up in milliseconds now takes seconds to cold start. The deployment that took 30 seconds now takes 5 minutes.

Dependencies all the way down

If speed were the only issue, I could live with it. But as services grow and get used, they start to depend on one another.

When using microservices, we typically need an orchestration layer that consumes those services. Not only does this layer grow over time, but it’s common for the microservices themselves to accumulate application logic that isn’t easy to externalize. A service that was supposed to be a simple data accessor now contains validation rules, business logic, and workflow coordination.

Imagine you’re building an e-commerce checkout flow. You might have:

• An inventory service to check stock
• A pricing service to calculate totals
• A payment service to process transactions
• A shipping service to calculate delivery options
• A notification service to send confirmations

Where does the logic live that says "only charge the customer if all items are in stock"? Or "apply the discount before calculating shipping"? This orchestration logic has to live somewhere, and it often ends up scattered across multiple services or duplicated in various places.

Who knows how microservices work?

As microservices grow, it’s inevitable that they grow teams around them. A team specializes in managing a service and becomes the domain expert. Not a bad thing on its own, but it becomes an issue when someone debugging a client-side problem discovers the root cause lies in a service only another team understands.

A problem that could have been solved by one person now requires coordination, meetings, and permissions to identify and resolve.

For example, a customer reports that they’re not receiving password reset emails. The frontend developer investigates and confirms the request is being sent correctly. The issue could be:

• The account service isn’t triggering the email request properly
• The email service is failing to send messages
• The email service is sending to the wrong queue
• The notification preferences service has the user marked as opted-out
• The rate limiting service is blocking the request

Each of these components is owned by a different team. What should be a 30-minute investigation becomes a day-long exercise in coordination. The feature spans across several microservices, but domain experts only understand how their specific service works. There’s a disconnect between how a feature functions end-to-end and the teams that build its components.

Microservices are slow(er)

When each microservice requires an actual HTTP request (or message queue interaction), things get relatively slower. Loading a page that requires data from several dependent services, each taking 50-100 milliseconds, means those latencies quickly compound.

Imagine for a second you are displaying a user profile page. Here is the data that’s being loaded:

• User account details (Account Service: 50ms)
• Recent orders (Order Service: 80ms)
• Saved payment methods (Payment Service: 60ms)
• Personalized recommendations (Recommendation Service: 120ms)
• Notification preferences (Settings Service: 40ms)

If these calls happen sequentially, you’re looking at 350ms just for service-to-service communication, before any actual processing happens. Even with parallelization, you’re paying the network tax multiple times over. In a monolith, this would be a few database queries totaling perhaps 50ms.

It’s not entirely useless

There are some real benefits to microservices, especially when you have good observability in place. When a bug is identified via distributed tracing, the team that owns the affected service can take over the resolution process. Independent deployment means that a critical security patch to your authentication service doesn’t require redeploying your entire application. Different services can use different technology stacks suited to their specific needs.

These address real pain points that people have and is why we are attracted to this architecture in the first place. But Microservices are not a solution to every architectural problem.

I always say if everybody is "holding it wrong," then they’re not the problem, the design is.

Microservices have their advantages, but they’re just one option among many architectural patterns. To build a good system, we don’t have to exclusively follow one style. Maybe what many organizations actually need isn’t microservices at all, but what I’d call "macroservices". Larger, more cohesive service boundaries that group related functionality together.

Instead of separate services for user accounts, authentication, and authorization, combine them into an identity service. Instead of splitting notification into separate services for email, SMS, and push notifications, keep them together where the shared logic and coordination naturally lives.

The goal should be to draw service boundaries around business capabilities and team ownership, not around technical functions. Make your services large enough that a feature can live primarily within one service, but small enough that a team can own and understand the entire thing.

Microservices promised us speed and independence. What many of us got instead were distributed monoliths, all the complexity of a distributed system with all the coupling of a monolith.

---