Microservices vs monolith: how to choose, and when to stay monolithic

Start with a monolith unless you have a specific reason not to. A well-structured monolith is faster to build, cheaper to run and easier to change while you are still learning what the product needs. Move to microservices when particular problems appear, such as teams blocking each other's releases, parts of the system needing very different capacity, or data that must be isolated for security or compliance.

What each architecture means

A monolith is one application, deployed as one unit, usually with one database. A modular monolith is the same, but with firm internal boundaries. Each module owns its data and talks to the others through defined interfaces, rather than reaching into their tables.

Microservices split the system into small services. Each one owns one business capability and its own data, talks to the others over the network through APIs or events, and can be deployed and scaled on its own.

Microservices vs monolith, side by side

• Speed to first release: a monolith is faster. Microservices need deployment pipelines, service discovery and monitoring in place before the first feature ships.
• Deployment: a monolith ships everything together, so one bad change can hold up a release. Microservices deploy independently.
• Scaling: a monolith scales as a whole. Microservices scale only the busy parts, which can save money at high load.
• Data consistency: a monolith can rely on database transactions. Microservices need patterns such as sagas, outboxes and idempotent consumers to keep data in step.
• Testing and debugging: simpler in a monolith, where one stack trace shows the problem. Microservices need contract tests and distributed tracing.
• Performance: calls inside a monolith are fast. Network calls between services add latency and new ways to fail.
• Running costs: a monolith needs less infrastructure and less operations skill. Microservices need container orchestration, observability and on-call cover for many moving parts.
• Team structure: a monolith suits one team or a few. Microservices suit several teams that each own a business area end to end.

When to stay monolithic

A monolith, ideally a modular one, is the better choice when:

• You have one or two development teams.
• The product is young and its boundaries are still moving. Splitting along the wrong lines is expensive to undo.
• No single part needs to scale very differently from the rest.
• You don't have the people to run container platforms and distributed monitoring.
• Your real problems are slow queries, missing tests or tangled code. Microservices won't fix those. They spread them across a network.

Martin Fowler made this case in his essay Monolith First. He observed that almost all the successful microservice stories he had heard of started with a monolith that grew too big and was broken up, and that almost all the systems he had heard of being built as microservices from scratch ended up in serious trouble.

Signs it is time to split

• Teams regularly wait for each other to release, or a release needs coordination across the whole company.
• One part of the system, such as search, tracking or notifications, needs far more capacity than the rest, and scaling everything is wasteful.
• A failure in a minor feature takes down the core product.
• One area needs separate security or compliance controls, such as payment or health data.
• Build and test times have grown so long that developers avoid running them.

One of these signs usually justifies extracting one service. It rarely justifies rewriting the whole system.

How to migrate without a rewrite

A full rewrite pauses feature work for a long time and carries a lot of risk. The safer route is the strangler fig pattern. You put a routing layer in front of the existing system, build a new service for one capability at a time, and move traffic across gradually.

1. Draw the boundaries first. Use business capabilities, such as orders, billing or notifications, not technical layers.
2. Add observability before you split. You need tracing and metrics to see whether the new service behaves.
3. Extract from the edges. Start with a capability that has few dependencies and a clear benefit from being separate.
4. Give each service its own data. Tables shared between services bring back the coupling you were trying to remove.
5. Keep both paths working. Move traffic in steps, and keep the old path available until the new one has proved itself.

For a regional logistics company, we broke a growing all-in-one platform into focused services for orders, dispatch, tracking, notifications and billing. High-value modules went first, so the work happened without a full rewrite. Busy tracking and notification workloads now scale on their own, and teams can release a service without redeploying everything.

Sometimes you don't need to split the core at all. A hotel group's ageing property management system had no modern API. We wrapped it in an API layer with caching and live data sync, and built new guest features as separate services around it. New features no longer need risky changes to the core, and the platform reached 99.99% system availability with 45ms API responses.

Where to start

Write down the specific problem you want the architecture to solve, and how you will know it is solved. If you can't name one, keep the monolith and spend the effort on module boundaries, tests and the database. If you can, pick the one capability that would gain most from being separate, and plan that extraction on its own.

Our microservices architecture and monolith to microservices teams can review your system with you. Our post on scalable software development covers what to fix before you split anything.