A 5-engineer startup that adopts microservices trades one repository for four, one deploy for an orchestration job, and one stack trace for correlating logs from four processes. You pay that trade in week two, before any scale benefit shows up.
What microservices give you
Microservices is an architectural style: the application becomes small independent services, each running its own process, talking over API or message. Each service covers one business capability and scales on its own.
You also take on the operational bill for that split: a deploy pipeline per service, request tracing across processes, and four systems that must answer together. Sam Newman covers these effects in Building Microservices (O'Reilly, 2021), including the "distributed monolith" that appears when services depend on each other at runtime.
Netflix left the monolith with hundreds of engineers behind it
Netflix and Amazon popularized service architecture. Netflix migrated from a monolith that blocked its growth and already employed hundreds of engineers to run video at scale. Amazon built platform teams whose job was to hide service complexity from the rest of the company.
Martin Fowler and James Lewis describe the style in "Microservices" (2014) and advise starting with a monolith while the domain keeps moving. Fowler repeats the order in "MonolithFirst" (2015): split the code before you split the process.
You have 3 to 8 engineers trying to prove that someone will pay for the product. No platform team exists to absorb the complexity, and the domain changes after every customer conversation.
You pay in week two
- Deploys become coordination. You version APIs between services, set publish order, and keep backward compatibility. The pull request for one screen becomes three PRs across repositories.
- Debugging becomes archaeology. The error that used to throw one stack trace now needs logs from four processes matched by timestamp.
- Testing becomes infrastructure. Proving the services talk takes a local environment someone maintains, or a staging environment billed by the hour.
- Onboarding becomes context. A hire in week two reads four codebases before touching production.
Nicole Forsgren, Jez Humble, and Gene Kim show in Accelerate (2018) that delivery speed tracks deployment frequency and lead time. A pipeline per service pushes both indicators the wrong way.
When microservices pay for themselves
The split earns its cost in two concrete situations:
- Separate teams must ship parts of the system without waiting on each other
- One part of the system takes a hundred times the load of another, search against account signup for instance
The split also earns its cost once business domain boundaries hold steady. A startup still hunting for product-market fit sits far from that point.
The modular monolith splits code inside one process
A modular monolith keeps one process and cuts the code by domain: each module with its own data layer and interfaces. You gain code boundaries without gaining network hops, API contracts, or chained releases. Eric Evans named these boundaries bounded contexts in Domain-Driven Design (Prentice Hall, 2003).
When the monolith hits its scale ceiling, you extract services from code that already sits in domain order. Extraction turns into infrastructure work.
The pattern growing startups run on
Start with a modular monolith cut along domain lines. Grow to its ceiling, which sits higher than most teams expect. Pull one service out when a concrete problem shows up: two teams stuck in one repository, one component that alone takes ten times the load of the rest, one part of the system that needs a different stack.
Extracting services to look current swaps a future problem for a present one, and the present one costs a team of five engineers and twelve months of runway the most.
