Microservices Architecture: When It Helps and When It Hurts

Microservices became fashionable because large companies like Netflix and Amazon used them to solve real problems at scale. The mistake most teams make is adopting the solution before having the problem.

Microservices are the right choice when: independent deployment of services is valuable (different teams own different services and deploy on different schedules), services have genuinely different scaling profiles (your payment service needs 10x the compute of your notification service at peak), or you need technology heterogeneity (one service legitimately needs Python for ML, another needs Java for throughput).

Microservices are the wrong choice when: you have a small team (the operational overhead per service doesn't justify the split), you haven't identified stable service boundaries (splitting along the wrong boundaries means constant cross-service changes for every feature), or your primary motivation is "this is what modern architecture looks like" rather than a specific problem you're solving.

The costs that get underestimated: distributed tracing and observability become significantly more complex; every service boundary becomes a network call with latency and failure modes; local development requires running multiple services; testing across services requires coordination. These costs are manageable at scale but painful at small team size.

For most startups and new systems, the right path is a well-structured monolith with clear internal module boundaries. When you genuinely feel the pain that microservices solve — usually around independent deployment or scaling — you'll have enough understanding of your domain to draw the right service boundaries. Doing it earlier usually means drawing the wrong ones.