Microservices got sold as the architecture of serious engineering teams, so a lot of five-person startups adopted them to look serious. Then in 2023, Amazon, of all companies, published a case study about moving a service off microservices and cutting its costs by 90%. The lesson for startups isn't "microservices are bad." It's that you probably don't need them yet.
Key Takeaways
- Amazon Prime Video moved a monitoring service from microservices back to a monolith and cut infrastructure cost over 90% (Amazon, via The New Stack).
- Microservices add real operational overhead, network calls, orchestration, deployment complexity, that a small team pays for whether or not it needs them.
- For most startups the monolith is the right default well past the point people assume.
- Split out a service when a specific scaling or team-boundary problem demands it, not preemptively.
The Case That Surprised Everyone
In 2023, Amazon Prime Video's Video Quality Analysis team published how they'd built a monitoring tool as distributed microservices orchestrated by AWS Step Functions, with S3 as intermediate storage. It didn't scale the way they wanted: Step Functions became a bottleneck and they hit account limits, because the system ran multiple state transitions per second of video (The New Stack). Their fix was to collapse the distributed components into a single process, keeping data in memory instead of round-tripping through S3. The result was a 90%+ cost reduction. Amazon's own conclusion was measured: microservices and serverless work at high scale, but whether to use them "has to be made on a case-by-case basis" (devclass).
The reason this landed so hard is that it came from Amazon, the company most associated with service-oriented architecture. It gave everyone permission to admit what many already suspected: distributing a system has costs, and those costs aren't always worth it.
What Microservices Actually Cost a Small Team
Every service boundary you add is a network call that can fail, a deployment to coordinate, a place for data to get inconsistent, and a piece of infrastructure to monitor. At Amazon's scale, with hundreds of engineers, those costs buy independent scaling and team autonomy that are worth it. At a startup's scale, with eight engineers, you pay the full operational tax and get little of the benefit, because you don't have enough teams for the autonomy to matter or enough load for the independent scaling to pay off.
| Monolith | Microservices | |
|---|---|---|
| Operational overhead | Low | High |
| Right for | Small teams, most startups | Many teams, high independent scale |
| Failure modes | Simpler | Network, orchestration, consistency |
| When to choose | Default | When a specific problem demands it |
A Concrete Version
A Series A team of eight splits their product into twelve microservices because that's "how you're supposed to build it." Now a simple feature touches four services, so it needs four deployments, four sets of tests, and careful handling of what happens when service B is up but service C is down. A change that would have been a 50-line PR in a monolith becomes a distributed-systems problem. They spend scarce senior time on orchestration and observability instead of product. The same team on a well-structured monolith ships the feature in an afternoon.
The Honest Counterpoint
This isn't "monoliths always win." Microservices exist because they solve real problems: when you have many teams that need to deploy independently, or one component with wildly different scaling needs than the rest, splitting it out is exactly right. And a monolith can rot into an unmaintainable mess if you never modularize it internally. The goal isn't "never split." It's "don't split preemptively." Build a well-organized monolith, keep clean module boundaries inside it, and carve out a service when a specific, present problem, a real scaling wall or a real team-autonomy need, actually justifies the cost. Let the pain tell you when. Martin Fowler's "MonolithFirst" argument, start with a monolith and extract services later, predates the Amazon case and matches it (Fowler).
What This Means for Hiring
Architecture choices are really judgment choices, and judgment is what you're hiring for. A senior engineer who's felt the pain of premature microservices will steer you toward the boring, right default and split only when it's warranted, which saves you months. That kind of hard-won judgment about what not to build is exactly what we screen for in how to verify a senior engineer, and it's a running theme in engineering org structure for startups. See available engineers.
Frequently Asked Questions
Should a startup use microservices?
Usually not by default. Microservices add operational overhead that pays off at large scale and in many-team organizations. Most startups are better served by a well-structured monolith until a specific problem forces a split.
Why did Amazon move from microservices to a monolith?
For one Prime Video service, the distributed design (Step Functions plus S3) hit bottlenecks and account limits. Collapsing it into a single in-memory process cut costs over 90%. Amazon framed it as a case-by-case call, not a universal rule.
When should we split into microservices?
When a specific, present problem demands it: a component with very different scaling needs, or multiple teams that must deploy independently. Split in response to real pain, not preemptively.
Isn't a monolith just technical debt waiting to happen?
Only if you never modularize it. A monolith with clean internal boundaries stays maintainable for a long time and is far cheaper to run than a premature distributed system.
The Bottom Line
When Amazon publishes a 90% cost cut from un-distributing a service, the "always use microservices" era is over. For a startup, the monolith is the right default far longer than the conference talks suggest. Keep it modular, split out a service only when a real problem demands it, and spend your senior engineers' time on product instead of orchestration.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
