A five-person startup running eleven repositories and a Kubernetes cluster for 200 users has the same problem as a 400-engineer company queuing behind one four-hour deploy pipeline. Both chose an architecture to match an identity, not a constraint. The microservices vs monolith question is really about team size, deployment pain, and how well you understand your own domain.
Here is the short version. A monolith is an application built and deployed as a single unit: one codebase, one build, one artefact. Microservices split the application into small, independently deployable services that communicate over a network, each owning its own data. Monoliths trade independence for simplicity; microservices make the opposite trade, and the price is paid in operations, indefinitely.
The decision is organisational before it is technical
A single well-written service on modern hardware can absorb enormous load. What a single codebase absorbs badly is thirty teams releasing into it at once, and that is the actual problem microservices exist to solve.
DORA's work on loosely coupled architecture finds that teams able to test and deploy without waiting on other teams deliver faster and more reliably. Note that DORA measures loose coupling, not service count: a well-modularised monolith can be loosely coupled, and eighty services that must deploy together are just a distributed monolith with added latency.
Ownership matters more than architecture. The O'Reilly Microservices Adoption survey of 1,502 practitioners found fewer than 10% called their adoption a complete success, and teams owning the full lifecycle of their services reported success at a rate 18 percentage points higher.
Martin Fowler calls the recurring cost of distributed systems the microservice premium: per-service deployment, distributed monitoring, partial failure handling, and eventual consistency. In MonolithFirst he observes that nearly every successful microservices system he had seen began as a monolith, while those built as microservices from day one routinely ran into serious trouble. Inside a monolith, a wrong boundary costs a refactor; across a network, it costs API versioning and data migration.
The reversals are real, and they teach a specific lesson
The most quoted correction comes from inside Amazon. The Prime Video Video Quality Analysis team rebuilt its monitoring workflow from a distributed serverless design into a single process in one ECS task, and the consolidation cut infrastructure costs by 90% while scaling further than before. Segment went further: after splitting its integrations platform into more than 140 services, the team drowned in per-service queues and divergent library versions, and eventually returned to a monolith.
The CNCF 2024 Annual Survey shows the same trimming across the ecosystem: service mesh adoption fell from 50% to 42% year on year while cloud native adoption sat at an all-time high of 89%. Teams are dropping complexity that fails to pay rent, not retreating from distributed systems.
Amazon did not abandon microservices; one team fixed one badly bounded service. Wrong boundaries are expensive in any system design architecture, and a network call is the most expensive boundary to get wrong. The trade is simple: monoliths are cheap now and constraining later, microservices are expensive now and liberating later, if your boundaries are right.
The chart is an illustrative summary: monoliths win the early-stage dimensions, microservices win the at-scale ones, and your job is to know which side your organisation sits on today.
The modular monolith is the sensible default
Four questions settle most cases. How many engineers ship into this system, since below roughly 20 to 30 the premium is pure loss? Do parts of the system scale differently enough to justify isolation? How well do you know the domain, given that unstable boundaries are cheapest to redraw inside one process? And can you operate distributed systems today, with tracing, per-service CI/CD, mature on-call, and the everyday concerns of event-driven systems such as ordering, retries, and idempotency?
If the answers point towards staying together, the middle path is the modular monolith: one deployable unit, internally divided into components with enforced boundaries and per-component ownership. Shopify kept one of the largest Rails codebases in production as a single deployable, investing in componentisation with explicit dependency rules that preserved one pipeline while delivering the autonomy most companies chase through service splits.
A modular monolith is also the best launchpad for a later migration strategy towards services. Boundaries that survived reality in one process are the ones worth promoting to network APIs, and careful API design at that seam separates an extraction from an outage generator.
FAQ
Should a startup use microservices or a monolith?
Start with a monolith, ideally a modular one. A startup's scarcest resources are engineering time and domain knowledge, and microservices tax both: you pay the microservice premium while your service boundaries are still guesses.
When should you switch from a monolith to microservices?
Switch when recurring pain persists despite good internal modularity: teams blocked on a shared deploy queue, one workload with radically different scaling needs, or a component requiring a different stack. Extract the single most painful seam first, never a big-bang rewrite.
Your decision checklist
Count the engineers shipping into the system. Under about 30, default to a modular monolith.
Write down the specific recurring pain. "It feels messy" does not qualify.
Enforce internal module boundaries and per-module ownership first. Much of the pain ends here.
Extract one service with the strongest proven case, with a real contract and its own data.
Measure deploy frequency, incident rate, and cost for a quarter, and repeat only if the pain returns.
Neither architecture is a virtue. Both are bills you pay for different kinds of freedom, and the only real mistake is paying for freedom you do not need yet. If you are staring down a split, or a merge, and want a second opinion grounded in production data, talk to the engineering team at BeyondPixl Studio about an architecture review.