Monolith vs microservices decision guide

Monolith vs microservices is a decision about teams and domains, not about which architecture sounds more modern. Microservices pay off when independent scaling of one service, well-separated business domains, and teams larger than roughly 50 developers make network communication and distributed debugging worth the cost. Small teams, simple domains, MVPs and projects without distributed-systems experience should stay on a monolith.

Monolith vs microservices: what actually differs

Monolith vs microservices differs in deploy units and in how a change travels through the system, not in whether the software is well built. A monolith ships one deployable and one repository; a microservices system ships many small services that talk over a network, which turns every internal call into a remote call that can fail independently.

The four properties the lesson attaches to microservices are single responsibility, deploy independence, technology agnosticism and decentralised data. Each of those is a benefit only while the boundaries hold. Once two services share a database table or must be deployed together, you have paid the cost of distribution without collecting the benefit.

A useful way to read the trade-off is that the monolith optimises for the people writing and testing the code, while microservices optimise for the organisation and for scaling one part of the system on its own. Neither optimisation is free, and the second one costs network hops, observability tooling and eventual consistency.

Martin Fowler's MonolithFirst note makes the sequencing argument directly: teams that start with microservices often struggle to find service boundaries, while teams that start with a monolith can extract services once the boundaries become obvious in the code.

Amazon's Amazon Builders' Library documents what the operational side of that extraction looks like at scale, including the service ownership and instrumentation work that only becomes necessary after the split. Those pages are worth reading before committing to a distributed architecture, because they describe costs the introductory material usually skips.

Advantages and disadvantages of a monolith

A monolith's advantages are a single deploy and a single codebase that is easy to develop and test locally. Every developer runs the whole system, one pipeline ships it, and a change is visible end to end without tracing a request across service boundaries. That is why most projects start here, including the supermarket checkout example from the lesson, where inventory, a barcode reader, a price calculation and a payment call belong in one application.

The disadvantages appear as the system and the team grow. Independent scaling becomes difficult because you can only scale the whole application, a single technology stack serves every part of the product, every new hire must learn that stack, and a failure in one module can take down the rest of the process.

The hiring and team-splitting effect is the one people underestimate. When the stack is fixed, the whole engineering organisation converges on one skill set, and you cannot staff a team around a business specialism, such as payments or fraud, if that team still has to work inside the same codebase and release train.

That is the honest version of the monolith argument: it is a scaling and organisational limitation, not a code-quality limitation. A well-structured monolith with clear internal modules is a normal, supportable system, and a badly structured microservices system is not better.

Advantages and disadvantages of microservices

Microservices deliver independent scaling, freedom to pick a language per service, and fault isolation, and they charge for those with network complexity, distributed debugging and eventual consistency. You can scale the checkout service on Black Friday without scaling the user service, write a data-heavy service in Python, and let a failure in one service degrade a feature rather than the whole application.

The costs show up during incidents. Distributed debugging means following one request through several services before you find the failing one; the lesson describes an incident where the team ended up restarting services one by one until the broken one surfaced. Monitoring has to be assembled across services rather than reading one dashboard, and integration testing has to cover the wiring between services, not just each service.

Eventual consistency is the structural cost. Once data is decentralised, cross-service state is reconciled through asynchronous events, and the system is briefly inconsistent between the moment an event is published and the moment every consumer has processed it. That window has to be designed for, and it changes how features such as a balance or an order status can be displayed.

Data decentralisation does improve blast radius: a compromised service cannot read every table, because it only owns its own. That is a containment benefit, not a security guarantee, and it says nothing about whether the application meets any particular regulatory standard.

When microservices are the right call

Microservices are the right call when independent scaling is genuinely required, the business domains are already separated, the team is large, or one part of the product needs a different technology. Those four conditions are the ones the lesson identifies, and they are organisational signals, not code signals.

• Large team: past roughly 50 developers, service boundaries let you split work by scope and hire for business specialisms rather than for one shared stack. The lesson's example is Mercado Livre, where products, seller, buyer and payments are separate areas staffed by people with the matching background.

• Well-defined domains: insurance, products and sellers are areas of the business, and if those boundaries are already clear, services map onto them cleanly. Domain-driven design is the usual tool here, with the DDD Reference documenting the modelling vocabulary the lesson refers to.

• Independent scaling: scaling is usually discussed at the CPU or instance level, but the thing that has to be independent is the deploy and the capacity of one part of the system. Checkout and payment traffic rises on Black Friday; user traffic does not rise in the same proportion, so scaling both together wastes capacity.

• Different technologies per domain: a data-heavy service written in Python can use the ecosystem built for that work, while the rest of the platform stays on TypeScript, Java or Go. In practice companies tend to run two or three languages, not one per service.

Scaling itself splits into vertical and horizontal: vertical means giving the existing machine more memory, disk or CPU, and horizontal means adding more machines. Microservices make horizontal scaling per service practical, which is why the checkout example is the standard illustration.

When a monolith is the better choice

A monolith is the better choice for small teams, simple domains, MVPs and prototypes, and for teams with no distributed-systems experience. Each of those conditions removes the reason microservices exist, so splitting only adds network calls, deployment steps and debugging effort.

A small team is the clearest case. If the same few developers would touch every service, you have reproduced the monolith's coupling across a network, and you have added a deploy pipeline per service on top of it. Hiring people specifically to operate microservices is expensive, and the lesson's advice is to bring in an experienced engineer rather than replace the existing team.

A simple domain is the second case. A supermarket checkout that reads stock, calculates a total, scans a barcode and calls a payment provider does not need a payment service, a stock service and a home-screen service. The boundary count is a direct function of the domain's complexity, not of ambition.

Prototypes and MVPs are the third case, and this is where the sequencing argument matters most. An idea that has not been validated does not have stable boundaries, so services built now will be built on guesses. The lesson's advice is to build the monolith, test the idea, and extract services only if growth makes it necessary.

The absence of distributed-systems experience is the fourth case. Distributed tracing, idempotent retries, message ordering and partial failure are separate skills, and acquiring them during your first production incident is the expensive way to learn.

Microservices trade-offs at a glance

The table below compares the two architectures on the dimensions that actually change a decision. Scale and failure characteristics are the ones that differ most in operation, and they are also the ones teams underestimate when they estimate the migration.

Dimension	Monolith	Microservices
Deploy unit	One artefact, one pipeline	Many services, one pipeline each
Scaling	Whole application only	Per service, vertical or horizontal
Technology	One stack for everything	Two to three stacks in practice
Failure scope	One fault can affect the process	Faults are isolated per service
Debugging	Single process, single log stream	Distributed tracing across services
Data consistency	Transactions in one database	Eventual consistency over events
Team fit	Small teams, simple domains	Teams past roughly 50 developers
Best first target	MVPs and prototypes	One independently scaled domain

Treat the table as a set of questions rather than a scorecard. A project can answer yes to independent scaling and still be a poor microservices candidate if the domains are tangled or nobody can run the tracing stack.

The four hard problems after you split

Four problems appear after the split and stay: service-to-service communication, data consistency, distributed monitoring, and testing and deploying many services together. They are not implementation details to be solved once; they are ongoing work that consumes engineering time for the life of the system.

Communication is the first. Internal calls become network calls over a private or public network, and every one of them can be slow, retried or lost. The lesson notes that this is often a network you do not own, because the servers run on a cloud provider. The AWS Well-Architected Framework covers the reliability practices this forces onto the design.

Consistency is the second. Data sits in the service that owns it, and cross-service state is reconciled through asynchronous events, so there is always a window where two services disagree. That trade is deliberate, and it has to be visible in the product's behaviour.

Monitoring and diagnosis are the third. Several services have to be observed together, and the restarts-one-by-one incident from the lesson is the low-technology version of that problem. Automated tracing and centralised logs are what make the diagnosis tractable.

Deployment, versioning and integration testing are the fourth. Each service has its own release cadence, some may be serverless functions such as AWS Lambda, and integration tests have to cover the contracts between services. Teams often find that versioning a single large repository is harder than versioning several small ones, which reverses the usual assumption.

The consistent theme is that microservices move complexity rather than delete it. The complexity that lived in one large codebase becomes complexity in the network, the deployment pipelines and the observability stack.

FAQ

• When should you use microservices instead of a monolith? Use microservices when one part of the system must scale independently, when business domains are already clearly separated, when the team has grown past roughly 50 developers, or when one domain needs a different technology. If none of those conditions holds, a monolith is usually the better choice.

• How large should a team be before adopting microservices? The lesson puts the practical threshold at more than roughly 50 developers. Below that, service boundaries mostly add deployment and communication overhead, because the same people end up working across several services anyway.

• Can a monolith scale to a large Supabase? Yes. A monolith scales vertically by adding memory, disk or CPU, and horizontally by running more copies behind a load balancer. What it cannot do easily is scale one feature on its own, which is the specific problem microservices address.

• What is eventual consistency in microservices? Eventual consistency means data is synchronised between services through asynchronous events, so two services can briefly disagree about the same business fact. The system converges once every consumer has processed the event, and features that read across services have to tolerate the window.

• Why is debugging harder in microservices? A request crosses several services, so a failure has to be located by tracing the request through each hop instead of reading one log stream. The lesson describes an incident where the team restarted services one by one until the faulty one surfaced, which is the manual version of the same work.

• Do microservices require multiple programming languages? No. Technology agnosticism is a capability, not a requirement, and most companies run two or three languages rather than one per service. The lesson gives TypeScript with Python, and Java with Go, as the common pairings.

• Are microservices more secure than a monolith? Data decentralisation limits blast radius, because each service owns only its own data. That containment is not the same as a security or compliance guarantee, which comes from the controls the application and the organisation put around the system.

• Should an MVP start as a monolith? Yes. An unvalidated idea does not have stable service boundaries, so building services first means guessing where the lines go. Build the monolith, test the product, and extract services if growth makes independent scaling or team separation necessary.

• What skills does a team need before splitting a monolith? Distributed tracing, asynchronous messaging, idempotent retries, partial failure handling and per-service deployment pipelines. Without at least one engineer who has run these in production, the lesson's advice is to stay on the monolith and hire that experience first.

Turning the architecture decision into a written guide

The four conditions in this article, independent scaling, separated domains, a large team and mixed technologies, are simple to state but hard to explain in a live setting. That is the recurring problem with architecture lessons: the reasoning is clear while someone walks through it, and it evaporates the moment the session ends.

If you have recorded an explanation like that, whether it is an architecture walkthrough, an interview or a longer class, Skalablog turns the video into a written article you can review and publish. Paste the YouTube URL, let it transcribe the recording, and edit the draft into a guide your readers can search, reference and revisit when they are making the decision themselves.

Skala Blog

Source video