Why do small teams adopt microservices when they shouldn’t?
Small teams adopt microservices because the industry’s most visible engineering organizations (Netflix, Amazon, Google) use them, creating a cargo-cult pattern where teams copy the architecture without having the problems it was designed to solve.
Netflix employs over 2,500 engineers. Amazon has over 10,000 engineering teams. Google operates at a scale where a single service might handle 10 billion requests per day. These organizations adopted microservices because they had specific, proven problems that microservices solved: the need for hundreds of teams to deploy independently, the need to scale individual subsystems by 100x, and the organizational reality that no single engineer could understand the entire system.
A team of 7 engineers building a B2B SaaS product with 200 customers does not have these problems. But they read the Netflix tech blog, attend KubeCon, and conclude that microservices are the modern approach. The result is predictable: 7 engineers spend 38% of their time maintaining Kubernetes clusters, debugging inter-service communication, managing 12 deployment pipelines, and configuring service mesh networking instead of building the features their 200 customers are actually asking for.
What specific criteria should determine the architecture choice?
Five measurable criteria determine whether a team should use a monolith or microservices: team size, deployment cadence requirement, scaling heterogeneity, operational maturity, and data coupling.
Criterion 1: Team Size
Monolith if under 10 engineers. A team of 10 can maintain shared understanding of a single codebase. The communication overhead of microservices (API contracts, service versioning, distributed debugging) exceeds the autonomy benefits when the team fits in one meeting room. Consider microservices at 15 to 25 engineers. At this size, sub-teams begin to form naturally, and the need for independent deployment becomes genuine. Microservices likely justified above 30 engineers, where Conway’s Law makes service boundaries inevitable.
Criterion 2: Deployment Cadence Requirement
Monolith if deploying 1 to 5 times per day. A well-structured monolith with good CI/CD can deploy 5 times daily without coordination overhead. Consider microservices if different subsystems need different deployment frequencies. If the billing system deploys weekly (regulated, high-risk) but the recommendation engine deploys 10 times daily (experimental, low-risk), separating them makes sense. Monolith if uniform cadence suffices. If every part of the system can ship at the same rate, the coordination cost of microservices buys nothing.
Criterion 3: Scaling Heterogeneity
Monolith if all components scale together. If your entire application needs more capacity during peak hours and less during off-peak, horizontal scaling of the monolith is simpler and cheaper than scaling individual services. Consider microservices if one subsystem needs 10x the resources of others. A video transcoding service that needs 100 CPU cores while the rest of the application runs on 4 cores is a legitimate candidate for extraction. Measure before deciding. I have seen teams assume scaling heterogeneity that did not exist, extracting services based on predicted load that never materialized.
Criterion 4: Operational Maturity
Monolith if the team cannot answer these questions: How do we trace a request across 3 services? What is our service discovery mechanism? How do we handle partial failures in downstream services? How do we manage distributed transactions? If any of these questions produce uncertainty, the team is not ready for microservices. Each gap will produce production incidents. Minimum infrastructure for microservices: centralized logging, distributed tracing, circuit breakers, health checks, and automated deployment for every service. If this infrastructure does not exist, build it before extracting services, or accept that you are building a distributed system without the tools to operate it.
Criterion 5: Data Coupling
Monolith if most features need data from multiple domains. If 70% of your features require joins across what would be service boundaries, microservices create a distributed monolith: the same coupling with added network latency. Consider microservices if data domains are naturally independent. If the user profile system and the analytics system share almost no data, they can be separated without creating cross-service data dependencies. Test with module boundaries first. Before splitting into services, organize your monolith into modules with explicit data boundaries. If the modules frequently need each other’s data, services will need it too.
How should teams apply this rubric?
Score each criterion honestly. If 3 or more criteria favor the monolith, start with a well-structured monolith and revisit the decision in 12 months when the team and product have matured.
- All 5 favor monolith: Build a modular monolith. Invest in internal module boundaries. Revisit in 12 months.
- 3 to 4 favor monolith: Build a monolith with the option to extract specific services later. Identify the 1 to 2 criteria that favor microservices and design your monolith to make future extraction possible for those specific areas.
- 3 to 4 favor microservices: Microservices may be appropriate, but invest in operational infrastructure first. Budget 2 to 3 months for observability, CI/CD, and service mesh before extracting services.
- All 5 favor microservices: This is rare for teams under 10. If you genuinely score all 5 toward microservices, you likely have a complex product with unusual scaling requirements. Proceed with caution and experienced guidance.
The rubric is designed to counteract enthusiasm with evidence. Microservices are a valid architecture. They solve real problems. But they solve the problems of large organizations with complex scaling requirements, not the problems of small teams shipping their first product. The most courageous architectural decision a small team can make is to choose simplicity when the industry is shouting complexity.