Microservices vs Monolith

The word monolith is often used to mean a tangled codebase, and that muddles the decision. A tangled codebase is a quality problem that can exist in any architecture: services can be just as tangled, with the knots now running over the network. A monolith is a deployment decision. One application, one artefact, one release. Whether its inside is well organised is a separate question, and it is the question that actually determines how pleasant the system is to change.

A modular monolith answers that question on purpose. The application is divided into modules that follow business capabilities, such as orders, billing, catalogue, identity and notifications. Each module owns its tables and no other module queries them. Each exposes a small public interface and keeps the rest private. Modules communicate through those interfaces or through in-process events. Shopify has written publicly about running its core commerce application this way, and frameworks such as Spring Modulith exist specifically to support the pattern.

The structure only holds if something enforces it, because code review alone does not survive deadlines. Architecture tests such as ArchUnit on the JVM, Packwerk for Ruby, and dependency rules on import paths in TypeScript projects turn a boundary violation into a failing build. That is the point at which boundaries become real.

The distributed monolith is the failure mode worth naming, because it is what many microservices programmes actually produce. Services share a database, so a schema change needs several teams. Services call each other synchronously in long chains, so one slow dependency slows everything. Releases must be coordinated because contracts are not backwards compatible. The organisation pays for network calls, many pipelines and distributed debugging, and gets none of the independence it was buying. The cause is nearly always splitting before the boundaries were understood, or splitting the code without splitting the data.

Team autonomy at size is the strongest argument for microservices, and it concerns people before technology. A codebase shared by one or two teams is coordinated through conversation. Once several teams share it, coordination moves into process: release calendars, merge queues, owners for shared areas, and meetings to agree what goes out this week. The cost of that process grows with every team added, and at some point it exceeds the cost of running services. Where that point falls depends on the codebase and the culture, so watch for the symptoms instead of counting heads: deploys waiting on unrelated work, teams wary of touching shared code, and lead times growing while the work itself has not got harder.

Different runtime needs are the most clear-cut case, because they are physical. A web application serving requests wants many small instances that start quickly. A model serving predictions may need GPUs. A video pipeline wants large machines for minutes at a time and nothing in between. A nightly reconciliation job wants a great deal of memory once a day. Packing all of these into one deployable forces every instance to carry the most demanding requirement, or lets a heavy task starve the request path. Separating such components often makes sense even in a small organisation, and it does not mean going all the way to microservices. One or two services beside a monolith, or the same codebase deployed with separate entry points for web and worker processes, is frequently enough.

Independent scaling is the argument most often made and least often examined. A monolith scales horizontally perfectly well, and running more copies of the whole application costs little extra when most of its code sits idle in memory. The argument only bites when one component’s demand differs sharply from the rest and is expensive to supply, such as an ingestion endpoint taking a constant stream of device events, or a search component that needs large in-memory indexes. Scaling that component alone then saves money and shields everything else from its spikes. If you cannot name such a component, the scaling argument does not apply to you yet.

Failure isolation is the last of the conditions, and it has to be designed in. Splitting reporting into its own service only protects checkout if checkout does not call reporting synchronously, has its own resources, and behaves sensibly when its dependencies are slow. Services that call each other in chains share each other’s failures, sometimes more painfully than a monolith would. The isolation is real when the critical path depends on as few other services as possible and keeps working, in a reduced form if necessary, when one of them is unavailable.

Each service is a small product to operate. It needs a build and deployment pipeline, a runtime, configuration and secrets, health checks, scaling rules, logs, metrics, alerts, dependency upgrades and security patches. With one application, that work exists once. With twenty services, much of it exists twenty times, and it only stays manageable when it has been standardised into templates and shared tooling that someone owns.

Most microservices estates run on containers, and many on Kubernetes, which brings its own permanent operational load: cluster upgrades on a schedule you do not control, networking, ingress, policy, and add-ons with their own release cycles. Services do not require Kubernetes, and managed container platforms remove much of that burden. On AWS, for example, ECS on Fargate runs containers without a cluster for you to manage, and the other major clouds offer equivalents. Whether a cluster is justified is a separate decision, which we cover in Docker vs Kubernetes.

The larger cost is people. A microservices architecture assumes a platform function: engineers whose job is the shared pipelines, the observability stack, the service templates and the on-call experience of everyone else. Without that function the same work is scattered across product teams, done unevenly, and each team ends up solving deployment, logging and alerting slightly differently. Infrastructure bills also rise, because each service carries a baseline of instances, databases and monitoring whether it is busy or not. Cloud pricing is usage-based and changes often, so model it against the current rate cards.

None of this means microservices are too expensive. It means their cost is largely fixed and paid up front, while the benefit grows with the number of teams and the variety of workloads. A large organisation spreads the platform cost across many teams and comes out ahead. A small one pays much the same platform cost for a benefit it cannot yet use.

Inside a monolith, a function call either returns or throws. Across a network it can also hang, time out after the work was done, succeed twice, or fail on one side while the other believes it succeeded. The well-known list of fallacies of distributed computing opens with the assumption that the network is reliable, and every item on that list becomes a design decision once a system is split.

Each needs a specific answer. Every call needs a timeout, or one slow service ties up the threads of everything that calls it. Retries need backoff and limits, or a brief failure turns into a retry storm that keeps the failing service down. Operations that may be retried need to be idempotent, so that a payment request delivered twice charges once. Message consumers have to cope with duplicates and often with messages arriving out of order. Circuit breakers and fallbacks decide what the user sees when a dependency is unavailable, and that decision belongs to the product as much as to engineering.

Cascading failure is the characteristic incident. A dependency slows down rather than failing outright, its callers wait, their callers wait for them, connection pools fill, and a problem in a minor service becomes an outage on the main path. Monoliths have their own failures, such as a memory leak that takes down every instance or a bad release that breaks everything at once, but those are visible in one place and can usually be reproduced locally.

The practical consequence is that microservices need an engineering culture fluent in these patterns, and a test approach that exercises them, including deliberately injected latency and failure in non-production environments. Teams that adopt services without that fluency tend to discover each pattern in a production incident, one at a time.

Splitting code is the easy part of microservices. Splitting data is where the effort and the risk lie. The rule that makes services independent is that each one owns its data and no other service reads its tables directly. Once two services share a schema, neither can change it alone, and the independence the architecture promised has gone.

Owning data separately has consequences that reach the business. A query that used to be one join becomes a call to another service, or a local copy of another service’s data kept current through events. Reports that spanned the whole system need a pipeline into a warehouse. An operation that changed three tables in one transaction becomes a saga: a sequence of local transactions, each with a compensating action if a later step fails. Writing to a database and publishing an event reliably needs the transactional outbox pattern, because doing the two separately will eventually do one without the other.

This is why consistency requirements should drive the boundaries. Data that must change together belongs in the same service. If drawing the boundary you want means splitting a transaction the business relies on, the boundary is probably in the wrong place. Bounded contexts from domain-driven design are a useful tool here, because they start from where the language and rules of the business divide rather than from technical layers.

A modular monolith lets you practise all of this while it is still cheap to get wrong. Give each module its own schema, forbid cross-module table access, communicate between modules through interfaces or events, and keep transactions inside a module wherever you can. If a module can live by those rules inside the monolith, extracting it later is mostly a deployment change. If it cannot, you have learned that before paying for a network boundary.

Independent deployment is the main thing microservices offer, and it is only real if the contracts between services stay backwards compatible. If a change to one service requires another to be deployed at the same moment, they are not independent, whatever the repository structure says. That makes interface design a central discipline: versioning, additive changes, consumers that tolerate fields they do not recognise, and an expand-and-contract approach in which a new field or endpoint is added, consumers move over, and the old one is removed later. Treating interfaces as products is what good API development means in this setting.

Each service also needs its own pipeline, and the quality of that pipeline decides whether independence is usable. Automated tests, consumer-driven contract tests that catch a breaking change before it ships, progressive rollout and automatic rollback are what allow a team to deploy several times a day without fear. Without mature CI/CD, a fleet of services is simply a large number of manual releases.

A monolith has one pipeline and one release, which is simpler in every way until several teams share it. Then the symptoms are familiar: a long build, a test suite nobody fully trusts, release trains, and one team’s unfinished work holding up another team’s fix. Much of that can be relieved without touching the architecture. Feature flags let unfinished work ship switched off, build caching and test selection shorten the pipeline, and trunk-based development reduces merge pain. Try those before concluding that the only answer is to split.

When contention persists after those measures, and it is costing delivery time across several teams, the case for extracting services along team lines becomes strong. That is the point at which the architecture solves a problem you actually have.

In a monolith, a failed request leaves a stack trace showing its whole path through the code. In a microservices system the same request might cross a gateway, four services and a message broker, each logging only its own part. Without observability built in from the start, diagnosing a slow or failed request means lining up timestamps across several log streams and guessing.

The minimum is distributed tracing, so that one request can be followed across every service it touches; correlation identifiers carried through every call and message; structured logs collected centrally; and metrics for request rate, errors and latency per service. OpenTelemetry has become the vendor-neutral standard for producing traces, metrics and logs, which keeps your instrumentation independent of whichever backend stores and queries the data.

This has costs of its own. Telemetry volume grows with the number of services and calls, observability platforms commonly charge by data ingested or by usage, and sampling has to be decided so that what you keep is what you need. Alerting has to change too. Alerting on every service’s internal metrics produces noise, while alerting on what users experience, such as error rates and latency against agreed objectives, finds real problems.

A monolith benefits from the same practices and gets more from each hour spent on them. Structured logs, request identifiers, a handful of service-level metrics and an application performance tool cover most investigations. If your team does not yet do this well in one application, that is a reliable sign it is not ready to do it across twenty.

The case for starting with a monolith depends on building it so that splitting stays possible. Organise code by business capability rather than by technical layer, so that everything about orders lives together instead of being scattered across shared folders of controllers, services and repositories. Give each module a small public interface and keep its internals private. Let modules communicate through those interfaces or through in-process events, which can later become messages on a broker without changing the logic on either side.

Treat data the same way. One database is fine; one shared schema that every module reads freely is not. Separate schemas or clearly owned tables per module, and a rule that modules never join across each other’s tables, keep the most expensive part of a later extraction cheap. Send background work through a job queue from the start, so that heavy or slow tasks already run apart from the request path and can move to their own deployment when they need different resources.

Then watch for the signals that a module wants to leave: a team that owns it and keeps waiting on everyone else’s releases, a resource profile that forces every instance to be sized for it, a load pattern unlike the rest of the system, or a compliance boundary around its data. When one of those appears, extract that module and only that module. Plenty of well-run systems stay a modular monolith with two or three services beside it for years, and there is nothing unfinished about that.

The right way to move from a monolith to microservices is gradually, using the strangler fig pattern, named after the plant that grows around a host tree until it can stand on its own. Put a routing layer in front of the existing application, such as a reverse proxy or an API gateway. Build a new service for one capability, route that capability’s traffic to it, and leave everything else where it is. Repeat only for capabilities that have a reason to move. The old application shrinks over time and the system keeps working throughout.

Choose the first extraction carefully. A good candidate has a clear boundary, few synchronous dependencies on the rest of the system, data it can own outright, and a concrete reason to be separate. Separate its data inside the monolith before extracting the code: move its tables into their own schema, remove other modules’ direct access, and route reads through its interface. Use change data capture or an outbox to keep any remaining copies in step during the transition, and an anti-corruption layer to stop the old model’s quirks leaking into the new service.

Avoid the big-bang rewrite. Rebuilding a working monolith as a set of services in parallel and then switching over combines the risks of a rewrite with the risks of a new architecture, and it freezes the business while the new system chases an old one that keeps changing. Programmes that take this route tend either to stall or to ship a distributed monolith. Incremental extraction, planned as part of a wider legacy application migration where the old system also needs modernising, keeps the product shipping and lets you stop once the reason for splitting has been dealt with.

The reverse move is legitimate as well. Teams that split too early, or into services that were too small, sometimes merge them back into a single deployable application, and the result is often cheaper to run and easier to change. The same principles apply: consolidate one cluster of tightly coupled services at a time, keep the module boundaries inside the merged application, and treat the move as a correction based on evidence. Architecture should follow the organisation and the workload as they are now.